In the Linux kernel, the following vulnerability has been resolved:
smb: prevent use-after-free due to opencacheddir error paths
If opencacheddir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in opencacheddir() freeing the cfid while the queued work is pending.
Update opencacheddir() to drop refs rather than directly freeing the cfid.
Have cacheddirleasebreak(), cfidslaundromatworker(), and invalidateallcacheddirs() clear haslease immediately while still holding cfids->cfidlistlock, and then use this to also simplify the reference counting in cfidslaundromatworker() and invalidateallcacheddirs().
Fixes this KASAN splat (which manually injects an error and lease break in opencacheddir()):
================================================================== BUG: KASAN: slab-use-after-free in smb2cachedlease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65
CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2cachedleasebreak Call Trace: <TASK> dumpstacklvl+0x77/0xb0 printreport+0xce/0x660 kasanreport+0xd3/0x110 smb2cachedleasebreak+0x27/0xb0 processonework+0x50a/0xc50 workerthread+0x2ba/0x530 kthread+0x17c/0x1c0 retfromfork+0x34/0x60 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 2464: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 _kasankmalloc+0xaa/0xb0 opencacheddir+0xa7d/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 _dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64after_hwframe+0x76/0x7e
Freed by task 2464: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x51/0x70 kfree+0x174/0x520 opencacheddir+0x97f/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 _dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64after_hwframe+0x76/0x7e
Last potentially related work creation: kasansavestack+0x33/0x60 _kasanrecordauxstack+0xad/0xc0 insertwork+0x32/0x100 _queuework+0x5c9/0x870 queueworkon+0x82/0x90 opencacheddir+0x1369/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 _dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64afterhwframe+0x76/0x7e
The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)