In the Linux kernel, the following vulnerability has been resolved:
9p: add missing locking around taking dentry fid list
Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it:
UAF thread: refcountt: addition on 0; use-after-free. p9fidget linux/./include/net/9p/client.h:262 v9fsfidfind+0x236/0x280 linux/fs/9p/fid.c:129 v9fsfidlookupwithuid linux/fs/9p/fid.c:181 v9fsfidlookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fsvfsgetattrdotl+0xf9/0x360 linux/fs/9p/vfsinodedotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248
Freed by: p9fiddestroy (inlined) p9clientclunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9fidput linux/./include/net/9p/client.h:278 v9fsdentryrelease+0xb5/0x140 linux/fs/9p/vfsdentry.c:55 v9fsremove+0x38f/0x620 linux/fs/9p/vfsinode.c:518 vfsunlink+0x29a/0x810 linux/fs/namei.c:4335
The problem is that dfsdata was not accessed under dlock, because drelease() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fsremove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible.