| Message ID | tencent_A7845DD769577306D813742365E976E3A205@qq.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [next] fs: fix oob in do_handle_open | expand |
On Wed, 2024-04-03 at 14:54 +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)) { > retval = -EFAULT; > goto out_handle; > } cc'ing Gustavo, since it looks like his patch in -next is what broke this.
On Wed, Apr 03, 2024 at 04:48:17AM -0400, Jeff Layton wrote: > On Wed, 2024-04-03 at 14:54 +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)) { > > retval = -EFAULT; > > goto out_handle; > > } > > cc'ing Gustavo, since it looks like his patch in -next is what broke > this. I'ved folded the fix into Gustavo's patch. Please see https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.misc&id=02426828cde24cd5b6cf5f30467cea085118f657
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. Honza
On 03/04/24 02:48, Jeff Layton wrote: > On Wed, 2024-04-03 at 14:54 +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)) { >> retval = -EFAULT; >> goto out_handle; >> } > > cc'ing Gustavo, since it looks like his patch in -next is what broke > this. > Oh, sorry about that folks. That looks pretty much like a copy/paste error. The fix is correct. Thanks, Edward! -- Gustavo
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. :)
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)) { retval = -EFAULT; goto out_handle; }
[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(-)