CVE-2023-52751

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix use-after-free in smb2_query_info_compound()<br /> <br /> The following UAF was triggered when running fstests generic/072 with<br /> KASAN enabled against Windows Server 2022 and mount options<br /> &amp;#39;multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm&amp;#39;<br /> <br /> BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> Read of size 8 at addr ffff888014941048 by task xfs_io/27534<br /> <br /> CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> Call Trace:<br /> dump_stack_lvl+0x4a/0x80<br /> print_report+0xcf/0x650<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __phys_addr+0x46/0x90<br /> kasan_report+0xda/0x110<br /> ? smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> ? smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs]<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __stack_depot_save+0x39/0x480<br /> ? kasan_save_stack+0x33/0x60<br /> ? kasan_set_track+0x25/0x30<br /> ? ____kasan_slab_free+0x126/0x170<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> ? __pfx_smb2_queryfs+0x10/0x10 [cifs]<br /> ? __pfx___lock_acquire+0x10/0x10<br /> smb311_queryfs+0x210/0x220 [cifs]<br /> ? __pfx_smb311_queryfs+0x10/0x10 [cifs]<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __lock_acquire+0x480/0x26c0<br /> ? lock_release+0x1ed/0x640<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? do_raw_spin_unlock+0x9b/0x100<br /> cifs_statfs+0x18c/0x4b0 [cifs]<br /> statfs_by_dentry+0x9b/0xf0<br /> fd_statfs+0x4e/0xb0<br /> __do_sys_fstatfs+0x7f/0xe0<br /> ? __pfx___do_sys_fstatfs+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? lockdep_hardirqs_on_prepare+0x136/0x200<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Allocated by task 27534:<br /> kasan_save_stack+0x33/0x60<br /> kasan_set_track+0x25/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> open_cached_dir+0x71b/0x1240 [cifs]<br /> smb2_query_info_compound+0x5c3/0x6d0 [cifs]<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> smb311_queryfs+0x210/0x220 [cifs]<br /> cifs_statfs+0x18c/0x4b0 [cifs]<br /> statfs_by_dentry+0x9b/0xf0<br /> fd_statfs+0x4e/0xb0<br /> __do_sys_fstatfs+0x7f/0xe0<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Freed by task 27534:<br /> kasan_save_stack+0x33/0x60<br /> kasan_set_track+0x25/0x30<br /> kasan_save_free_info+0x2b/0x50<br /> ____kasan_slab_free+0x126/0x170<br /> slab_free_freelist_hook+0xd0/0x1e0<br /> __kmem_cache_free+0x9d/0x1b0<br /> open_cached_dir+0xff5/0x1240 [cifs]<br /> smb2_query_info_compound+0x5c3/0x6d0 [cifs]<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> <br /> This is a race between open_cached_dir() and cached_dir_lease_break()<br /> where the cache entry for the open directory handle receives a lease<br /> break while creating it. And before returning from open_cached_dir(),<br /> we put the last reference of the new @cfid because of<br /> !@cfid-&gt;has_lease.<br /> <br /> Besides the UAF, while running xfstests a lot of missed lease breaks<br /> have been noticed in tests that run several concurrent statfs(2) calls<br /> on those cached fids<br /> <br /> CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...<br /> CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...<br /> CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108<br /> CIFS: VFS: Dump pending requests:<br /> CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...<br /> CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...<br /> CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108<br /> ...<br /> <br /> To fix both, in open_cached_dir() ensure that @cfid-&gt;has_lease is set<br /> right before sending out compounded request so that any potential<br /> lease break will be get processed by demultiplex thread while we&amp;#39;re<br /> still caching @cfid. And, if open failed for some reason, re-check<br /> @cfid-&gt;has_lease to decide whether or not put lease reference.