CVE-2026-97594: landlock: Fix use-after-free of the source's parent directory
In the Linux kernel, the following vulnerability has been resolved:
landlock: Fix use-after-free of the source's parent directory
currentcheckreferpath() reads olddentry->dparent without holding a reference nor a lock on it, and then dereferences it in collectdomainaccesses() and in the audit record.
A reference on a child does not pin its parent: dmove() reassigns dentry->dparent and drops the reference the child held on its former parent. hookpathrename() is not affected because the rename path calls lockrename() before the hook, so the source cannot be reparented under it. hookpathlink() has no such protection: filenamelinkat() holds a reference on the source dentry but neither locks nor references its parent, so a concurrent rename(2) can reparent the source while securitypathlink() runs, and the former parent can then be removed and freed while the hook walks it.
A process can trigger this after entering a Landlock domain that handles at least one filesystem access right. The process can then race a linkat(2) loop against rename(2) and rmdir(2):
BUG: KASAN: slab-use-after-free in collectdomainaccesses+0x278/0x290 Read of size 4 at addr ffff888160bd53f4 by task llrepro2/549 collectdomainaccesses+0x278/0x290 currentcheckreferpath+0x952/0x1120 securitypathlink+0x1be/0x320 filenamelinkat+0x342/0x6d0 x64syslinkat+0xfa/0x150 Freed by task 562: kmemcachefree+0x139/0x4c0 icallback+0x4b/0x80 rcucore+0x7dc/0x10a0
Take a reference on the dentry selected as the source parent, using dget() for the common-mount-root case and dgetparent() otherwise. Release it after the hierarchy walk and synchronous audit logging.
[mic: Clarify the caller, reachability, and reference handling]
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
A process must first enter a Landlock domain that handles at least one filesystem access right. It must then race linkat(2) operations against concurrent rename(2) and rmdir(2) operations involving the source path.
Is the rename path itself affected?
No. The rename hook is protected because the rename path calls lock_rename() before the hook runs, preventing the source from being reparented during that operation. The affected path is the link operation, which lacks equivalent protection for the source parent directory.
What is the immediate mitigation if the kernel fix cannot be deployed?
Avoid allowing untrusted processes in Landlock domains with filesystem access rights to perform or coordinate the relevant linkat(2), rename(2), and rmdir(2) race. The issue requires concurrent filesystem operations after the process has entered such a Landlock domain.