CVE-2026-89560: Linux Kernel Privilege Escalation Flaw

CVE-2026-89560 Overview

CVE-2026-89560 is a Linux kernel vulnerability in the Landlock Linux Security Module. The flaw involves incorrect access control enforcement during whiteout object creation used by OverlayFS implementations. Before the fix, renameat2(2) with the RENAME_WHITEOUT flag created a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. The mknod(2) path for whiteouts was also gated by the wrong permission class (LANDLOCK_ACCESS_FS_MAKE_CHAR instead of LANDLOCK_ACCESS_FS_MAKE_REG). A local, sandboxed process can bypass intended Landlock file-system restrictions to create filesystem entries that should be blocked.

Critical Impact
A local unprivileged process confined by Landlock can bypass filesystem access control policy, undermining sandbox integrity and permitting integrity and availability impact on affected kernels.

Affected Products

Linux kernel branches that ship the Landlock LSM prior to the fix commits
Userspace OverlayFS stacks that rely on Landlock confinement (for example, fuse-overlayfs)
Container and sandbox runtimes that depend on Landlock policy for file-system isolation

Discovery Timeline

2026-09-11 - CVE-2026-89560 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-89560

Vulnerability Analysis

Landlock is the Linux kernel LSM that lets unprivileged processes sandbox themselves against filesystem operations. Whiteout objects are special entries used in an OverlayFS upper layer to mask files present in a lower layer. Userspace OverlayFS daemons create them through mknod(2) with S_IFCHR and makedev(0, 0), or through renameat2(2) with the RENAME_WHITEOUT flag.

The kernel VFS exempts this specific S_IFCHR creation from CAP_MKNOD because a whiteout is not a real character device and is not bound to a driver. Landlock, however, previously classified the mknod(2) path under LANDLOCK_ACCESS_FS_MAKE_CHAR, which is intended for privileged device creation. The renameat2(2) path was worse: it created the whiteout directory entry even when every LANDLOCK_ACCESS_FS_MAKE_* right was denied.

The fix reclassifies whiteout creation under LANDLOCK_ACCESS_FS_MAKE_REG, aligning the check with the actual privilege boundary (unprivileged, like regular file creation) and enforcing it on both syscall paths. A Landlock erratum records the change in semantics for the mknod(2) case.

Root Cause

The root cause is inconsistent and missing access-control mapping in the Landlock LSM hooks for whiteout creation. The mknod(2) hook checked the wrong right class, and the renameat2(2)RENAME_WHITEOUT hook failed to enforce any LANDLOCK_ACCESS_FS_MAKE_* right, resulting in a policy bypass [Broken Access Control].

Attack Vector

Exploitation requires local, authenticated access with the ability to run code inside a Landlock-confined domain. An attacker inside such a sandbox can invoke renameat2() with RENAME_WHITEOUT to create a directory entry that policy should have blocked, or use mknod() to create whiteout objects under a MAKE_CHAR-only policy. This weakens sandbox guarantees for container tooling and userspace OverlayFS stacks that rely on Landlock to constrain filesystem writes.

No verified proof-of-concept code has been published. See the upstream patches for the exact enforcement changes: Kernel Commit 0c3204aa and Kernel Commit efb4f24f.

Detection Methods for CVE-2026-89560

Indicators of Compromise

Unexpected character-device entries with major/minor 0,0 created by non-root processes inside sandboxed workloads
renameat2() calls with RENAME_WHITEOUT succeeding from processes whose Landlock ruleset denies filesystem creation rights
Presence of whiteout entries in directories that should be immutable under active Landlock policy

Detection Strategies

Audit running kernel versions across the fleet and flag hosts running Landlock-enabled kernels that predate the fix commits
Instrument syscall telemetry for mknod with S_IFCHR/makedev(0,0) and renameat2 with RENAME_WHITEOUT originating from confined workloads
Correlate Landlock policy definitions with observed filesystem creation events to surface allow/deny mismatches

Monitoring Recommendations

Enable auditd rules covering mknod, mknodat, rename, and renameat2 syscalls and forward events to a central analytics tier
Track OverlayFS upper-layer directories on multi-tenant hosts for new whiteout objects outside expected daemon activity
Baseline fuse-overlayfs and container runtime behavior so anomalous whiteout creation from other processes is visible

How to Mitigate CVE-2026-89560

Immediate Actions Required

Update to a Linux kernel build that includes the upstream Landlock whiteout patches referenced in the NVD entry
Inventory workloads that depend on Landlock for sandboxing and prioritize patching those hosts first
Re-test Landlock policies after patching to confirm whiteout creation is rejected as expected

Patch Information

The fix is delivered through the following upstream commits: Kernel Commit 0c3204aa, Kernel Commit 627ce490, Kernel Commit 672fa082, Kernel Commit d739e323, Kernel Commit dfb10d98, and Kernel Commit efb4f24f. Apply the vendor-provided kernel update for your distribution once it incorporates these commits.

Workarounds

Restrict local, untrusted code execution on hosts that cannot be immediately patched
Prefer kernel-native OverlayFS mounts over userspace fuse-overlayfs where feasible, since normal rename() operations there are checked against the daemon's Landlock domain rather than the caller's
Layer additional MAC controls (SELinux, AppArmor, seccomp) around sandboxed workloads to constrain mknod and renameat2 usage

bash

# Confirm the running kernel version so you can compare it against
# the fixed commits published on git.kernel.org
uname -r

# Example: audit rules to log whiteout-relevant syscalls for review
auditctl -a always,exit -F arch=b64 -S mknod -S mknodat -k landlock-whiteout
auditctl -a always,exit -F arch=b64 -S renameat2 -k landlock-whiteout