CVE-2025-68736: Landlock Disconnected Directory Fix in Linux Kernel

The Linux kernel CVE-2025-68736 addresses a subtle Landlock sandboxing bug: landlock: Fix handling of disconnected directories, a behavior change intended to prevent access-right widening when processes interact with files or directories that have become disconnected from a bind-mount point.

Background / Overview​

Landlock is a Linux LSM-like facility aimed at giving unprivileged processes a way to define file system access policies (domains) that constrain their own future file operations. Landlock's design relies on properly evaluating access rights along the relevant directory and mount hierarchies when decisions such as file rename or permission checks occur. On December 24, 2025, a CVE entry (CVE-2025-68736) was published that documents a correctness/robustness fix in Landlock’s handling of disconnected directories — directories visible and opened via a bind mount but subsequently renamed or moved in a way that detaches them from the mount point’s visible path. The National Vulnerability Database (NVD) entry records the problem and the rationale for the upstream fix. At a high level, the problem was that Landlock’s previous logic could collect access rights for an opened file or directory by walking the filesystem hierarchy down to the root, without correctly accounting for the mount point when the mount point could not be discovered during that walk. This mismatch meant that permission sets used to compare source and destination access could be inconsistent — most worryingly, it could allow a rename to succeed in cases where that rename would effectively widen a sandboxed task’s access rights relative to the Landlock policy. The upstream remedy ensures the mount-point context is included in the access computation even when the mount point cannot be found by a straightforward hierarchy walk. The advisory and aggregated vulnerability trackers (OSV, CVE aggregators) echo the same summary and link the CVE to kernel stable commits that implement the change upstream. These independent records corroborate the behavioral description and the intent to make Landlock’s behavior safer and less surprising to users.

---

What exactly went wrong — technical anatomy​

Disconnected directories explained​

A disconnected directory in this context is a directory that remains open and accessible via an existing file descriptor or a bind mount reference, but whose original path (the source side of the bind mount) has been renamed, moved, or removed such that the directory is not reachable from the mount point anymore. Practically, this situation can arise when:

• A process opens a directory via a bind mount (or a bind mount is created), and later the source filesystem tree is modified (rename/move/unlink) such that the original mount point no longer reflects the prior structure; or
• System workflows or privileged utilities perform renames that cut the opened handle off from the mount’s visible namespace.

Because the kernel can have live references to inodes that do not appear on a current path from the mount point, any code that derives access rights by walking the inode-to-root chain must take mounts into account; otherwise it may traverse a different tree (the underlying filesystem root) that does not reflect the mount’s view. The mismatch is particularly dangerous for Landlock because it compares access sets calculated for both the source and the destination in rename operations to ensure no rights are widened by the rename.

The core bug​

Prior to the fix, Landlock’s logic could collect access rights by walking the related hierarchy up to the filesystem root without finding a mount point (because the mount point is not necessarily discoverable when the hierarchy is disconnected). That meant the collected rights could be drawn from the underlying filesystem layout rather than from the mount’s visible ancestry. As a result, when comparing source and destination access rights as part of a rename operation, a sandboxed task could appear to have sufficient rights because the collection used hidden filesystem hierarchy rather than the mount-point hierarchy the task should be constrained by. The consequence: a rename could effectively widen access rights in a way not intended by the Landlock policy.

Conditions required to create a disconnected directory​

The kernel advisory notes that for a sandboxed task to create a disconnected directory it would need specific write privileges on the underlying source of the bind mount (for example FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) and read access to the related mount point. Because Landlock’s model guarantees a process cannot obtain more access rights than its domain allows, missing the mount-point inheritance could yield inconsistent results: permissions that should have been inherited from the mount-point hierarchy were missing, while permissions hidden behind the mount could be incorrectly included instead. That subtle inversion is what the fix aims to eliminate.

---

The upstream fix — what changed​

The kernel maintainers modified Landlock’s access-collection behavior so that when a file or directory is opened from a disconnected directory, the logic:

• Accounts for the filesystem hierarchy when the mount point is not found during the walk, and
• Always also considers the mount point from which the disconnected directory was originally opened.

This means the collected access rights used to evaluate operations such as rename now reflect both the filesystem view and the mount-point context; the rename is rejected if allowing it would widen access rights when evaluated against these combined hierarchies. The change thereby avoids subtle denial or expansion-of-access mismatches that were previously possible. The NVD entry summarizes this intended behavior change. In addition to the behavioral change, the upstream patch removed a spurious WARN_ON_ONCE used as a canary in collect_domain_accesses and adjusted the related comment — a minor cleanup to remove noisy diagnostics that were not helpful for normal kernel operation. The advisory also clarifies that opened files have their access rights stored in file security properties and that there is no functional impact for disconnected or unlinked files beyond the corrected access-collection semantics.

---

Scope and severity — who should care​

Affected code and distributions​

The vulnerability is in the Linux kernel Landlock code path. Upstream patches have been committed into the stable kernel trees; distribution vendors will typically map those upstream stable commits into their packaged kernels and release updates accordingly. Aggregators such as OSV and public CVE trackers reflect the same narrative and list the kernel as the affected product. Administrators should verify their distribution’s kernel changelog or security advisory for package versions that include the upstream backport.

Practical impact​

• Primary impact: correctness/consistency of Landlock access decisions; the observed effect is that renames or other operations could be permitted in cases where an accurate evaluation should have denied them.
• Exploitability: This is not a remote code-execution bug; it is a local semantics/permission-check correctness issue. To reach the dangerous scenario, a process must be able to create or interact with disconnected directories through bind mounts and have the required write/read access to the source and mount point, respectively. That typically requires local privileges or a misconfiguration that allows a sandboxed task to perform mount-like or rename operations on untrusted inputs.

Why this matters operationally​

Landlock is used to confine unprivileged programs (e.g., sandboxed tools, language runtimes, helper daemons). If a sandbox’s enforcement is subtly incorrect, it undermines the trust model: administrators or developers who rely on Landlock policies to prevent certain file system actions may be misled into thinking rename operations and other file metadata operations cannot widen rights when, under specific disconnected-directory scenarios, they could. The patched behavior is intended to make Landlock’s semantics stricter and more intuitive — the safer default in a security control is to ensure operations are not allowed when there is ambiguity about the hierarchy.

---

Detection, verification and patch validation​

How to detect whether you’re affected​

• Inventory kernels: check whether your running kernel includes Landlock support and whether your vendor’s kernel package contains the stable backport that corresponds to CVE-2025-68736. Query your distribution security tracker and kernel package changelogs. Aggregators (OSV, NVD) already list the CVE and link upstream commit IDs or references; use those mappings to identify patched package versions for your distro.
• Search for Landlock usage: find processes or containers that rely on Landlock policies (common in constrained execution environments, packaged runtimes, or systemd sandboxing). Identify workloads that perform bind mounts, accept third-party images, or perform renames that could produce disconnected directory states.
• Audit mount and rename operations: if you operate systems that mount untrusted artifacts or allow user-level bind operations, log and audit those mount and rename operations. Kernel logs and auditd can help find anomalous sequences or repeated rename operations against bind mount sources. While there are no simple log signatures specific to the bug, correlating mount/rename events with Landlock-denied or -allowed operations can highlight suspicious behavior.

Verifying the fix after patching​

• After installing a kernel update that maps to the upstream fix, reboot into the updated kernel and exercise representative sandboxed workloads that relied on Landlock policies.
• Re-run any reproducer or test harnesses that previously demonstrated inconsistent rename decisions in your environment (if available) and verify that renames that would widen access rights are now denied by the kernel.
• If you maintain custom kernels, verify the presence of the upstream patch in your source tree by searching for code changes around Landlock’s collect_domain_accesses and code paths that compute access rights for opened directories in conjunction with mount-point handling. The upstream commit metadata is captured in public CVE listings.

---

Mitigation guidance and operational recommendations​

The nature of this CVE is correctness-focused, and the recommended remediation is straightforward: install vendor-supplied kernel updates that include the upstream stable backport and reboot hosts into those kernels.
Short-term mitigations for environments that cannot patch immediately:

• Restrict who may create and manipulate bind mounts. Limit untrusted users’ abilities to perform bind mounts or to rename directories under mount points, using capability controls and container privileges to limit operations that could create disconnected directories.
• Limit unsandboxed or untrusted tasks from having write access to mount-source directories. The advisory explains that both write access to the bind-source and read access to the mount point are preconditions for creating disconnected directories in the way that causes the problem.
• Use other LSM/namespace controls to reduce attack surface: AppArmor, SELinux, or conservative container profiles (drop CAP_SYS_ADMIN and any mount-related capabilities from untrusted containers) are effective stopgaps until kernels are patched.
• Monitor and audit mount and rename events; apply stricter operational controls on image ingestion or bind-mounting workflows in CI and multi-tenant environments.

Operational rollout checklist (recommended):

• Identify affected hosts and kernels: uname -r and vendor package changelog.
• Stage kernel updates in a test ring and validate Landlock-protected workloads.
• Roll out updates to production systems in waves, ensure reboots occur, and verify kernel versions after reboot.
• Monitor kernel logs and audit trails for anomalous mount/rename sequences during rollout.
• If patching is delayed, enforce stricter mount, bind, and rename policies and restrict access to mount sources.

---

Cross-checks and independent verification​

Multiple independent vulnerability databases and aggregator services (NVD, OSV, CVE Details, CVEFeed) list CVE-2025-68736 with consistent descriptions of the issue and point to the same upstream remediation intent. This cross-source consistency increases confidence that the issue is a Landlock correctness fix and that the patch is the intended remediation path. Administrators should still verify vendor package mappings for their specific distribution because distribution backporting can vary. Note: attempts to view a Microsoft Security Response Center (MSRC) page for CVE-2025-68736 may not render content in a headless or scripted fetch — the MSRC update-guide endpoint requires JavaScript and may return a client-side application message when accessed programmatically. The MSRC endpoint for the CVE shows the page’s app bootstrap content rather than the vulnerability details in a server-side response; in practice, users should view MSRC entries in a modern browser to confirm availability.

---

Strengths of the upstream response and potential residual risks​

Strengths​

• The upstream fix is conservative and defensive: it tightens semantics so the kernel errs on the side of denying operations that could widen access rights, which is the safer stance for a sandboxing primitive.
• The fix is narrow and focused on access-collection behavior rather than wholesale rework of Landlock semantics, which reduces regression risk and makes stable backports feasible for distributions.
• Multiple independent trackers have ingested the CVE and reflect the same remedial guidance, providing administrators with consistent signals to act on.

Residual risks and caveats​

• Patching lag: as with all kernel fixes, vendor and OEM kernels may lag upstream. Embedded device vendors, manufacturer kernels, or long-tail distributions may take longer to propagate the fix. Administrators in those environments must either engage vendors for backports or apply configuration mitigations to reduce exposure.
• Complexity of mount semantics: the mounting model in Linux is subtle, especially with bind mounts and namespaces. Operational misconfigurations or legacy workflows that rely on complex mount manipulations could still produce surprising states; hardening mount creation and rename workflows remains a sound practice.
• Attack chaining: while the described issue is a correctness problem, any kernel-level inconsistency in sandbox enforcement can be an enabler when combined with other bugs. Treat correctness fixes in enforcement code as high-priority even when direct exploitation appears limited.

---

Practical notes for developers and security engineers​

• If you rely on Landlock for sandboxing in user-facing tooling or CI pipelines, augment tests to include scenarios that involve bind mounts and rename operations across mount boundaries. Add integration tests that create and exercise disconnected-directory states to ensure your policies behave as expected after kernel updates.
• For kernels you build and maintain in-house, review the upstream change in the Landlock tree (the NVD and OSV entries reference upstream commits) and cherry-pick the stable commit into your build branches if you cannot update to a newer kernel version immediately. Validate the change in sanitized test environments before production rollout.

---

Conclusion​

CVE-2025-68736 is a correctness and robustness fix in Landlock’s access-collection semantics for disconnected directories. The underlying risk is not a remote arbitrary-code exploit; rather, it is a violation of the principle that a sandboxed process must not be able to widen its file-system access via operations that depend on inconsistent hierarchy walks. The kernel maintainers addressed the issue by ensuring the mount-point context is always considered when computing access rights for opened files and directories that are disconnected from a mount point, preventing renames that would otherwise widen access rights.
Administrators and kernel users should treat this CVE as actionable: verify whether your distribution’s kernels include the upstream stable backport, schedule patch and reboot windows for affected hosts, and apply the described operational mitigations where immediate patching is not possible. The fix is defensive and intended to make Landlock safer and more intuitive; deploying it will reduce the risk of surprising privilege widening in sandboxed workloads.

---

(If you maintain a browser-accessible MSRC feed or are using automated scanners that query vendor trackers, note that the MSRC update-guide endpoint may require an interactive browser to render the full advisory content; check vendor and distribution advisories or the NVD/OSV listings for directly viewable CVE detail.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center