| Message ID | 20240119153906.4367-1-n.zhandarovich@fintech.ru (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak | expand |
On Fri 19-01-24 07:39:06, Nikita Zhandarovich wrote: > syzbot identified a kernel information leak vulnerability in > do_sys_name_to_handle() and issued the following report [1]. > > [1] > "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] > BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 > instrument_copy_to_user include/linux/instrumented.h:114 [inline] > _copy_to_user+0xbc/0x100 lib/usercopy.c:40 > copy_to_user include/linux/uaccess.h:191 [inline] > do_sys_name_to_handle fs/fhandle.c:73 [inline] > __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] > __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 > __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 > ... > > Uninit was created at: > slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 > slab_alloc_node mm/slub.c:3478 [inline] > __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 > __do_kmalloc_node mm/slab_common.c:1006 [inline] > __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 > kmalloc include/linux/slab.h:604 [inline] > do_sys_name_to_handle fs/fhandle.c:39 [inline] > __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] > __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 > __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 > ... > > Bytes 18-19 of 20 are uninitialized > Memory access of size 20 starts at ffff888128a46380 > Data copied to user address 0000000020000240" > > Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to > solve the problem. > > Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") > Suggested-by: Chuck Lever III <chuck.lever@oracle.com> > Reported-and-tested-by: syzbot+09b349b3066c2e0b1e96@syzkaller.appspotmail.com > Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Makes sense. Feel free to add: Reviewed-by: Jan Kara <jack@suse.cz> Honza > --- > Link to Chuck's suggestion: > https://lore.kernel.org/all/B4A8D625-6997-49C8-B105-B2DCFE8C6DDA@oracle.com/ > > fs/fhandle.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/fhandle.c b/fs/fhandle.c > index 18b3ba8dc8ea..57a12614addf 100644 > --- a/fs/fhandle.c > +++ b/fs/fhandle.c > @@ -36,7 +36,7 @@ static long do_sys_name_to_handle(const struct path *path, > if (f_handle.handle_bytes > MAX_HANDLE_SZ) > return -EINVAL; > > - handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, > + handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, > GFP_KERNEL); > if (!handle) > return -ENOMEM; > -- > 2.25.1 >
On Fri, 19 Jan 2024 07:39:06 -0800, Nikita Zhandarovich wrote: > syzbot identified a kernel information leak vulnerability in > do_sys_name_to_handle() and issued the following report [1]. > > [1] > "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] > BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 > instrument_copy_to_user include/linux/instrumented.h:114 [inline] > _copy_to_user+0xbc/0x100 lib/usercopy.c:40 > copy_to_user include/linux/uaccess.h:191 [inline] > do_sys_name_to_handle fs/fhandle.c:73 [inline] > __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] > __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 > __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 > ... > > [...] Applied to the vfs.misc branch of the vfs/vfs.git tree. Patches in the vfs.misc branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.misc [1/1] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak https://git.kernel.org/vfs/vfs/c/1b380b340f19
diff --git a/fs/fhandle.c b/fs/fhandle.c index 18b3ba8dc8ea..57a12614addf 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -36,7 +36,7 @@ static long do_sys_name_to_handle(const struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; - handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM;
syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III <chuck.lever@oracle.com> Reported-and-tested-by: syzbot+09b349b3066c2e0b1e96@syzkaller.appspotmail.com Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> --- Link to Chuck's suggestion: https://lore.kernel.org/all/B4A8D625-6997-49C8-B105-B2DCFE8C6DDA@oracle.com/ fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)