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 dfsdata 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 vfsstatx+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.