Description

In the Linux kernel, the following vulnerability has been resolved: landlock: Fix use-after-free of the source's parent directory current_check_refer_path() reads old_dentry->d_parent without holding a reference nor a lock on it, and then dereferences it in collect_domain_accesses() and in the audit record. A reference on a child does not pin its parent: __d_move() reassigns dentry->d_parent and drops the reference the child held on its former parent. hook_path_rename() is not affected because the rename path calls lock_rename() before the hook, so the source cannot be reparented under it. hook_path_link() has no such protection: filename_linkat() holds a reference on the source dentry but neither locks nor references its parent, so a concurrent rename(2) can reparent the source while security_path_link() 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 collect_domain_accesses+0x278/0x290 Read of size 4 at addr ffff888160bd53f4 by task llrepro2/549 collect_domain_accesses+0x278/0x290 current_check_refer_path+0x952/0x1120 security_path_link+0x1be/0x320 filename_linkat+0x342/0x6d0 __x64_sys_linkat+0xfa/0x150 Freed by task 562: kmem_cache_free+0x139/0x4c0 i_callback+0x4b/0x80 rcu_core+0x7dc/0x10a0 Take a reference on the dentry selected as the source parent, using dget() for the common-mount-root case and dget_parent() otherwise. Release it after the hierarchy walk and synchronous audit logging. [mic: Clarify the caller, reachability, and reference handling]

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-25T11:17:10.653Z",
  "pubdate": "2026-09-25T11:17:10.653Z",
  "executiveSummary": "This vulnerability is a use-after-free (UAF) flaw within the Linux kernel's Landlock security module, specifically affecting the path-referencing mechanism during filesystem operations.\nThe vulnerability arises due to an improper reference handling of a dentry's parent directory within the current_check_refer_path() function.\nAn unprivileged local attacker can exploit this condition by racing a linkat(2) system call against concurrent rename(2) and rmdir(2) operations to trigger a UAF condition.\nSuccessful exploitation results in kernel memory corruption, leading to a system crash or potential arbitrary code execution, posing a significant risk to kernel stability and integrity.\nThe vulnerability is reachable for any process that has entered a Landlock domain with active filesystem access rights, making it a critical concern for containerized or restricted environments that rely on Landlock for sandboxing.",
  "technicalDetails": "The root cause of the vulnerability is the unsafe access of old_dentry->d_parent within current_check_refer_path(). The function accesses this pointer without holding a reference or a proper lock on the parent directory. Because dentry objects in the Linux VFS (Virtual File System) do not guarantee that a child pins its parent in memory, the parent can be modified or destroyed by concurrent filesystem operations.\nSpecifically, __d_move() can reassign a dentry's parent and drop the reference held by the child on the former parent. While hook_path_rename() avoids this race by utilizing lock_rename(), hook_path_link() does not implement similar protection. In the context of filename_linkat(), the kernel holds a reference on the source dentry but fails to secure the parent, leaving it susceptible to being unlinked and subsequently freed by rmdir(2) while the security hook is still iterating through the directory hierarchy in collect_domain_accesses().\nThe exploitation flow involves a race condition. An attacker initiates a linkat(2) system call, which invokes the vulnerable Landlock hook. Simultaneously, the attacker executes a rename(2) operation to move the source dentry to a different parent and uses rmdir(2) to remove the original parent directory. If the kernel's Landlock logic attempts to audit or collect access rights on the original parent while the memory has already been reclaimed by the slab allocator, the system will perform a read operation on a freed memory address.\nThis results in a slab-use-after-free error, as evidenced by the KASAN report pointing to collect_domain_accesses+0x278/0x290. The vulnerability exposes the kernel's memory management to an attacker-controlled race, where the freed memory may be reallocated to another process, potentially allowing for controlled data manipulation or a kernel panic due to invalid dereferencing of pointers within the freed slab object.\nThe impact is significant, as Landlock is designed to provide granular security boundaries. A bypass or crash of this module undermines the kernel's defensive posture, especially in environments where Landlock is the primary enforcement mechanism for restricting process interaction with the filesystem."
}