On December 24, a critical correctness fix for the Linux kernel’s Landlock security module was published as CVE-2025-68736. The bug could allow programs confined by Landlock’s sandbox to perform file renames that inadvertently expand their file system access rights—a direct violation of the sandbox’s foundational promise: that an unprivileged process cannot widen its own permissions. While the flaw requires specific local conditions to exploit, it chips away at the trust model that makes Landlock a popular choice for container runtimes, sandboxed browsers, and systemd service hardening.

The Hidden Paths Landlock Missed

Landlock, merged into the mainline kernel in version 5.13, lets unprivileged processes voluntarily restrict their own file operations. It’s integrated into tools like Flatpak, Bubblewrap, and systemd’s sandboxing features. The mechanism works by defining rulesets that tie access to specific directories or file hierarchies. Programs can then drop privileges and rely on Landlock to prevent themselves from straying beyond allowed paths.

The bug centered on how Landlock computed access rights for files or directories opened through bind mounts, particularly when a directory becomes “disconnected” from its mount point. A disconnected directory is one that remains accessible via an open file descriptor or a bind mount reference, but the original source path has been renamed, moved, or unlinked—severing its visible connection to the mount’s namespace.

Under the old logic, when Landlock attempted to evaluate whether an operation (like a rename) would unlawfully widen a task’s file access, it walked the filesystem hierarchy upward to determine the inherited permissions. If the directory was disconnected, the walk might fail to locate the mount point and instead traverse the underlying filesystem root. Picture this: you’re in a room with a door that leads to a hallway. If someone removes the door, you might still look through the opening and see the hallway, but the hallway isn’t really part of the room’s layout anymore. Landlock was looking through that opening but treating the hallway as if it were still part of the room, collecting access rights from the hidden filesystem structure and omitting the mount’s view. This could let a sandboxed task execute a rename that, when assessed against the mount-aware hierarchy, would have been rejected as a rights escalation.

As the National Vulnerability Database entry notes, exploiting this required that a process have write privileges on the bind mount’s source directory (e.g., FS_MAKE_REG, FS_REMOVE_FILE, FS_REFER) and read access to the mount point itself. In practice, that means an attacker or a misconfigured sandboxed process with those capabilities could orchestrate a rename that opens up file access it shouldn’t have.

The fix, committed to the upstream kernel, ensures that Landlock’s access-collection function (collect_domain_accesses) always accounts for the mount point, even when it can’t be found by a straightforward hierarchy walk. It also removes a superfluous WARN_ON_ONCE that would fire in normal operation, reducing kernel noise.

The Real-World Impact

For Linux Administrators

If you manage Linux servers, containers, or endpoints and rely on Landlock policies—explicitly or implicitly—this bug matters. Tools that use Landlock under the hood may have had subtle enforcement gaps. For example:
- Container runtimes: If you use Docker or Podman with user namespaces enabled, Landlock is sometimes used to further restrict container processes. A disconnected directory scenario inside a container could allow a process to widen its file access within the container’s mount namespace.
- Flatpak/Snap packages: Sandboxed desktop applications use Landlock to prevent file system escapes. A malicious or buggy app might have been able to manipulate bind mounts to gain access to files outside its intended sandbox.
- systemd service hardening: Many systemd unit files use ProtectSystem, ProtectHome, and related directives which can leverage Landlock. A service with write access to a bind mount source could potentially escalate.

While the bug is not remotely exploitable, it’s a fundamental correctness issue that can erode the security boundary of any Landlock-based confinement. If your security model assumes that a sandboxed process cannot widen its own file access, this flaw invalidates that assumption in specific edge cases. The fix is not just a regular update—it’s a must-have for those relying on Landlock for security guarantees.

For Developers

If you’re building software that sandboxes itself or others with Landlock, audit your bind mount usage. The patch will change the behavior of your sandbox: renames that previously succeeded may now fail if they would widen access. This is the intended, safer outcome. Update your test suites to include scenarios with disconnected directories and verify that your application’s policies behave as expected after the kernel is patched. Also, if your application grants write access to bind mount sources, reconsider whether that’s actually necessary—reducing such permissions is a defense-in-depth measure.

For Windows IT Pros (Yes, This Matters to You Too)

This vulnerability is in the Linux kernel, not Windows. But if your organization runs Linux workloads—on premises, in Azure VMs, WSL2 on Windows 11, or mixed-OS environments—take note. Many Windows admins manage Linux servers or developer machines with WSL. A flaw in Landlock could affect security boundaries in those systems. Microsoft’s own Security Response Center lists this CVE, reflecting its cross-platform relevance to enterprises (though the MSRC advisory page was light on details due to JavaScript rendering requirements).

The Long Road to a Safer Sandbox

Landlock was designed from the start to be safe for unprivileged use, but its file system access model intersected with one of Linux’s most intricate subsystems: mount namespaces and bind mounts. The kernel’s VFS (Virtual File System) layer handles a lot of complexity behind the scenes. When bind mounts are combined with renames and inode relationships, edge cases multiply.

The bug’s discovery likely came from careful review of Landlock’s hierarchy-walking logic. It was assigned CVE-2025-68736, with an NVD publication date of December 24, 2025—suggesting it was responsibly disclosed and patched. The fix landed in upstream stable kernels, and distribution vendors are now rolling out backports. The CVE aggregators (OSV, CVE Details, etc.) all mirror the same description, confirming the technical nature and the intent of the correction.

This isn’t the first time Linux mount semantics have tripped up security modules. The interaction between bind mounts and access control has been a source of bugs in SELinux and AppArmor as well. Landlock’s design philosophy—delegating policy enforcement to the program itself—makes such correctness issues especially sensitive: if the kernel silently gets the hierarchy wrong, the program’s self-imposed jail can have hidden doors.

What to Do Now: Patch, Verify, Mitigate

1. Update Your Kernel

The primary remediation is to install a kernel update that includes the backported fix. Check your distribution’s security advisory for packages that close CVE-2025-68736. Most major distributions (Debian, Ubuntu, Fedora, RHEL, openSUSE) will have updates soon after the upstream stable point releases. After updating, a reboot is required.

How to check if you’re patched:
- Look at your kernel build’s changelog for references to the CVE or the Landlock fix commits.
- Run uname -r and compare with your distribution’s tracking page.
- For custom kernels, search your source tree for the patch that modifies security/landlock/ around collect_domain_accesses.

2. Verify Your Sandboxed Workloads

Once updated, re-run any automated tests that exercise Landlock policies, especially those involving file renames across directories. If you maintain test harnesses, add a regression test that does the following under a Landlock domain:
- Create a bind mount to a directory.
- Open the mounted directory.
- Rename the original source directory so it becomes disconnected.
- Attempt a rename operation that would widen access.
The update should cause that rename to fail with EACCES (or another permission error) where it previously succeeded.

3. Short-Term Mitigations if Patching Is Delayed

If you can’t update immediately, reduce the attack surface:
- Restrict which users or processes can create bind mounts. Remove CAP_SYS_ADMIN from untrusted containers and processes.
- Limit write access to directories that are used as bind mount sources.
- Use additional LSM policies (SELinux, AppArmor) to confine processes that use Landlock, providing defense-in-depth until the Landlock fix is in place.
- Audit mount and rename system calls with tools like auditd to spot unusual activity involving bind mounts.

4. Stay Informed

Monitor your distribution’s security mailing list and the NVD entry for any updates. The fix is narrow, so regressions are unlikely, but stay alert for any reports of unexpected behavior after patching.

A Stronger Sandbox Going Forward

The Landlock team’s response demonstrates the maturity of the subsystem: a defensive correction that errs on the side of stricter enforcement. The patch removes a subtle, hard-to-trigger anomaly that nonetheless could undermine the security of sandboxed applications. As Landlock adoption grows—it’s now used in ChromeOS’s sandboxing, among other places—such correctness fixes are essential.

For the broader community, this CVE is a reminder that sandboxing primitives aren’t magic; they rely on rigorous kernel implementation. The Linux ecosystem’s swift handling of the bug shows that even edge-case bypasses are treated seriously. Keep your kernels current, and review your sandbox configurations for unusual mount operations. The fix is already filtering through distribution channels, so the risk window is closing.

In a world where attackers constantly search for ways to breach containers and break out of jails, a patched Landlock is a stronger link in the chain.