linux-kernel - Re: [linux-next:master] [fs] 1b43c46297: kernel_BUG_at

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240405-basisarbeit-kohlenkeller-676735d80a89@brauner>
Date: Fri, 5 Apr 2024 12:26:10 +0200
From: Christian Brauner <brauner@...nel.org>
To: Jan Kara <jack@...e.cz>
Cc: kernel test robot <oliver.sang@...el.com>, 
	syzbot <syzbot+4139435cb1b34cf759c2@...kaller.appspotmail.com>, Edward Adam Davis <eadavis@...com>, 
	"Gustavo A. R. Silva" <gustavoars@...nel.org>, oe-lkp@...ts.linux.dev, lkp@...el.com, 
	Linux Memory Management List <linux-mm@...ck.org>, linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org, 
	amir73il@...il.com, chuck.lever@...cle.com, jlayton@...nel.org, 
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: [linux-next:master] [fs]  1b43c46297: kernel_BUG_at_mm/usercopy.c

On Wed, Apr 03, 2024 at 01:03:16PM +0200, Jan Kara wrote:
> On Wed 03-04-24 10:46:19, Christian Brauner wrote:
> > On Wed, Apr 03, 2024 at 02:54:14PM +0800, Edward Adam Davis wrote:
> > > [Syzbot reported]
> > > BUG: KASAN: slab-out-of-bounds in instrument_copy_from_user_before include/linux/instrumented.h:129 [inline]
> > > BUG: KASAN: slab-out-of-bounds in _copy_from_user+0x7b/0xe0 lib/usercopy.c:22
> > > Write of size 48 at addr ffff88802b8cbc88 by task syz-executor333/5090
> > > 
> > > CPU: 0 PID: 5090 Comm: syz-executor333 Not tainted 6.9.0-rc2-next-20240402-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
> > > Call Trace:
> > >  <TASK>
> > >  __dump_stack lib/dump_stack.c:88 [inline]
> > >  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
> > >  print_address_description mm/kasan/report.c:377 [inline]
> > >  print_report+0x169/0x550 mm/kasan/report.c:488
> > >  kasan_report+0x143/0x180 mm/kasan/report.c:601
> > >  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
> > >  instrument_copy_from_user_before include/linux/instrumented.h:129 [inline]
> > >  _copy_from_user+0x7b/0xe0 lib/usercopy.c:22
> > >  copy_from_user include/linux/uaccess.h:183 [inline]
> > >  handle_to_path fs/fhandle.c:203 [inline]
> > >  do_handle_open+0x204/0x660 fs/fhandle.c:226
> > >  do_syscall_64+0xfb/0x240
> > >  entry_SYSCALL_64_after_hwframe+0x72/0x7a
> > > [Fix] 
> > > When copying data to f_handle, the length of the copied data should not include
> > > the length of "struct file_handle".
> > > 
> > > Reported-by: syzbot+4139435cb1b34cf759c2@...kaller.appspotmail.com
> > > Signed-off-by: Edward Adam Davis <eadavis@...com>
> > > ---
> > >  fs/fhandle.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/fhandle.c b/fs/fhandle.c
> > > index 53ed54711cd2..8a7f86c2139a 100644
> > > --- a/fs/fhandle.c
> > > +++ b/fs/fhandle.c
> > > @@ -202,7 +202,7 @@ static int handle_to_path(int mountdirfd, struct file_handle __user *ufh,
> > >  	*handle = f_handle;
> > >  	if (copy_from_user(&handle->f_handle,
> > >  			   &ufh->f_handle,
> > > -			   struct_size(ufh, f_handle, f_handle.handle_bytes))) {
> > > +			   f_handle.handle_bytes)) {
> > 
> > Groan, of course. What a silly mistake. Thanks for the fix.
> > I'll fold this into:
> > Fixes: 1b43c4629756 ("fs: Annotate struct file_handle with __counted_by() and use struct_size()")
> > because this hasn't hit mainline yet and it doesn't make sense to keep
> > that bug around.
> > 
> > Sorry, that'll mean we drop your patch but I'll give you credit in the
> > commit log of the original patch.
> 
> Indeed, I should have caught this during review. Sorry for that and thanks
> for fixing this up quickly.

Fwiw, it wasn't meant that way. I meant it's a silly mistake in the
sense that it is so easy to miss because the patch looks so benign. The
fact is that we will have to live with missing things like this once in
a while and that is why we have testing bots as well. :)