All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
@ 2024-01-19 15:39 Nikita Zhandarovich
  2024-01-22 10:43 ` Jan Kara
  2024-01-22 11:03 ` Christian Brauner
  0 siblings, 2 replies; 3+ messages in thread
From: Nikita Zhandarovich @ 2024-01-19 15:39 UTC (permalink / raw)
  To: Chuck Lever
  Cc: Nikita Zhandarovich, Jeff Layton, Amir Goldstein, Alexander Viro,
	Christian Brauner, Jan Kara, linux-fsdevel, linux-nfs,
	linux-kernel, syzbot+09b349b3066c2e0b1e96

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(-)

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


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
  2024-01-19 15:39 [PATCH] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak Nikita Zhandarovich
@ 2024-01-22 10:43 ` Jan Kara
  2024-01-22 11:03 ` Christian Brauner
  1 sibling, 0 replies; 3+ messages in thread
From: Jan Kara @ 2024-01-22 10:43 UTC (permalink / raw)
  To: Nikita Zhandarovich
  Cc: Chuck Lever, Jeff Layton, Amir Goldstein, Alexander Viro,
	Christian Brauner, Jan Kara, linux-fsdevel, linux-nfs,
	linux-kernel, syzbot+09b349b3066c2e0b1e96

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
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
  2024-01-19 15:39 [PATCH] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak Nikita Zhandarovich
  2024-01-22 10:43 ` Jan Kara
@ 2024-01-22 11:03 ` Christian Brauner
  1 sibling, 0 replies; 3+ messages in thread
From: Christian Brauner @ 2024-01-22 11:03 UTC (permalink / raw)
  To: Nikita Zhandarovich
  Cc: Christian Brauner, Jeff Layton, Amir Goldstein, Alexander Viro,
	Jan Kara, linux-fsdevel, linux-nfs, linux-kernel,
	syzbot+09b349b3066c2e0b1e96, Chuck Lever

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-01-22 11:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-19 15:39 [PATCH] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak Nikita Zhandarovich
2024-01-22 10:43 ` Jan Kara
2024-01-22 11:03 ` Christian Brauner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.