EUVD-2026-76471
GHSA-r9r3-96fh-8fhv
Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
Local process in Landlock domain (AV:L/PR:L) exploits missing authorization check without complexity (AC:L); scope changes because the Landlock security boundary is crossed; no confidentiality impact but high integrity and availability impact from unauthorized whiteout creation.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
6DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation
Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems.
For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well:
- mknod(2) with S_IFCHR and makedev(0, 0)
- renameat2(2) with RENAME_WHITEOUT,
creating the whiteout in the old place of the moved file.
This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver.
LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1].
For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG.
For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied.
This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there.
Depends-on: 49c9e09d9610 ("landlock: Fix handling of disconnected directories") Depends-on: fe72ce6710cb ("landlock: Add errata documentation section") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]
AnalysisAI
Landlock LSM in Linux kernel 5.13+ fails to enforce filesystem creation restrictions for whiteout objects across two distinct syscall paths, enabling a sandboxed process to escape its Landlock domain constraints. The renameat2(2) syscall with RENAME_WHITEOUT performs no Landlock MAKE_* access control check whatsoever, allowing any Landlock-restricted process to create whiteout directory entries even when all filesystem creation rights are denied; separately, mknod(2)-based whiteout creation was gated on the incorrect permission class (MAKE_CHAR instead of MAKE_REG). …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | The renameat2 bypass requires: (1) a Linux kernel 5.13 or later with CONFIG_SECURITY_LANDLOCK compiled and active; (2) the attacking process is executing under an active Landlock ruleset that has denied all LANDLOCK_ACCESS_FS_MAKE_* filesystem creation rights; (3) the process retains write access to at least one directory on a writable filesystem (the renameat2 call must succeed at the VFS permission level for a source path that can be renamed). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H) is accurately calibrated: exploitation is local-only, requires low privileges, needs no user interaction or race conditions, and the scope change correctly denotes a Landlock sandbox boundary escape. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Vendor-released patch is available: upgrade to Linux 6.18.50, 7.2.4, or 7.3-rc1 or later, applying the upstream stable commits at https://git.kernel.org/stable/c/627ce4902df1d737e99306daae5a87c68b876d16 (6.18.x), https://git.kernel.org/stable/c/672fa082d48b21e1fb62cdb184fee41513e53421 (7.2.x), or https://git.kernel.org/stable/c/0c3204aacbe8c07f9e87e3028f28ec6c166a1075 (7.3-rc1+). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, audit your infrastructure for Landlock deployment by reviewing kernel module configurations and container runtime policies, particularly in Kubernetes and container orchestration environments. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Share
External POC / Exploit Code
Leaving vuln.today