Received-SPF: pass (google.com: domain of linux-nfs+bounces-2662-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 5 Apr 2024 12:26:10 +0200
From: Christian Brauner <brauner@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: kernel test robot <oliver.sang@intel.com>, 
	syzbot <syzbot+4139435cb1b34cf759c2@syzkaller.appspotmail.com>, Edward Adam Davis <eadavis@qq.com>, 
	"Gustavo A. R. Silva" <gustavoars@kernel.org>, oe-lkp@lists.linux.dev, lkp@intel.com, 
	Linux Memory Management List <linux-mm@kvack.org>, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, 
	amir73il@gmail.com, chuck.lever@oracle.com, jlayton@kernel.org, 
	linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk
Subject: Re: [linux-next:master] [fs]  1b43c46297: kernel_BUG_at_mm/usercopy.c
Message-ID: <20240405-basisarbeit-kohlenkeller-676735d80a89@brauner>
References: <202404031550.f3de0571-lkp@intel.com>
 <000000000000f075b9061520cbbe@google.com>
 <tencent_A7845DD769577306D813742365E976E3A205@qq.com>
 <20240403-mundgerecht-klopapier-e921ceb787ca@brauner>
 <20240403110316.qtmypq2rtpueloga@quack3>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240403110316.qtmypq2rtpueloga@quack3>

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@syzkaller.appspotmail.com
> > > Signed-off-by: Edward Adam Davis <eadavis@qq.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. :)