From owner-freebsd-security Wed Nov 17 14:21:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8ED9B14D02 for ; Wed, 17 Nov 1999 14:21:27 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA08508; Wed, 17 Nov 1999 15:21:25 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA19404; Wed, 17 Nov 1999 15:21:42 -0700 (MST) Message-Id: <199911172221.PAA19404@harmony.village.org> To: Kelly Yancey Subject: Re: kernel stack contents visible from userland Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Wed, 17 Nov 1999 12:01:40 EST." References: Date: Wed, 17 Nov 1999 15:21:42 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Kelly Yancey writes: : Is there any security concern with a portion of the kernel's stack being : visible from userland? The reason I ask is that while investigating : another issue, I noticed that stat family of calls (and probably others) : leave kernel stack contents into userland via spare struct stat fields (I : imagine other structures have similar behavior with regards to the padding : between fiels for alignment). These patches look good. I wonder if there might be an easier way to accomplish this. I don't see anything here that is a security risk, per se, since most of the stat struct is always filled in before the copyout. Which fields in stat are not explicitly used? I would have expected them all to be filled in in all cases. It would likely be faster to just wonk on st_lspare and st_qspare[2] in cvstat... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message