From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH v2] fs: select: fix information leak to userspace Date: Sun, 14 Nov 2010 18:06:43 -0800 Message-ID: <20101114180643.593d19ac.akpm@linux-foundation.org> References: <1289421483-23907-1-git-send-email-segooon@gmail.com> <20101112120834.33062900.akpm@linux-foundation.org> <8D90F8B2-EA29-4EB9-9807-294CE0D5523B@dilger.ca> <20101114092533.GB5323@albatros> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Andreas Dilger , kernel-janitors@vger.kernel.org, Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Vasiliy Kulikov Return-path: In-Reply-To: <20101114092533.GB5323@albatros> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, 14 Nov 2010 12:25:33 +0300 Vasiliy Kulikov wrote: > On some architectures __kernel_suseconds_t is int. On these archs > struct timeval has padding bytes at the end. This struct is copied to > userspace with these padding bytes uninitialized. This leads to leaking > of contents of kernel stack memory. > > Signed-off-by: Vasiliy Kulikov > --- > Patch v1 used memset(), it was waste of cycles on almost all archs. > > Compile tested. > > fs/select.c | 7 ++++--- > 1 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/fs/select.c b/fs/select.c > index b7b10aa..43d4805 100644 > --- a/fs/select.c > +++ b/fs/select.c > @@ -288,7 +288,6 @@ static int poll_select_copy_remaining(struct timespec *end_time, void __user *p, > int timeval, int ret) > { > struct timespec rts; > - struct timeval rtv; > > if (!p) > return ret; > @@ -306,8 +305,10 @@ static int poll_select_copy_remaining(struct timespec *end_time, void __user *p, > rts.tv_sec = rts.tv_nsec = 0; > > if (timeval) { > - rtv.tv_sec = rts.tv_sec; > - rtv.tv_usec = rts.tv_nsec / NSEC_PER_USEC; > + struct timeval rtv = { > + .tv_sec = rts.tv_sec, > + .tv_usec = rts.tv_nsec / NSEC_PER_USEC > + }; > > if (!copy_to_user(p, &rtv, sizeof(rtv))) > return ret; Please check the assembly code - this will still leave four bytes of uninitalised stack data in 'rtv', surely.