Description
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]
Published: 2026-09-11
Score: 8.4 High
EPSS: < 1% Very Low
KEV: No
Impact: Local File System Manipulation
Action: Patch Now
AI Analysis

Impact

The Linux kernel contained a missing Landlock guard that allowed an unprivileged local user to create or move whiteout objects within an OverlayFS mount. Whiteouts are used to represent deleted files in the upper layer of an overlay, and when forged or relocated they can re‑establish a file name that no longer exists in the lower layer, effectively hiding or overriding data visible to processes inside that overlay environment. This manipulation enables a local attacker to alter the unified view of a filesystem, potentially exposing or conce flaw is mapped to the access‑control weakness class CWE‑1220.

Affected Systems

All Linux kernel installations that expose the OverlayFS feature—both the built‑in kernel overlay and the user‑space fuse‑overlayfs. No specific product or version list is available, so administrators should treat all unpatched kernel releases as affected.

Risk and Exploitability

The CVSS score of 8.4 indicates a high severity vulnerability that can be exploited locally. The EPSS score of less than 1% and its absence from the CISA KEV catalog suggest that active exploitation is currently uncommon, but the flaw’s local nature and lack of a privileged requirement mean that any user who can write to an OverlayFS mount point can prepare the exploit. Successful exploitation requires invoking mknod(2) with S_IFCHR or renameat2(2) with RENAME_WHITEOUT, which are user‑space operations that can be performed by processes already executing with the same privileges that own the overlay mount.

Generated by OpenCVE AI on September 15, 2026 at 21:54 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a release that contains the Landlock patch enforcing LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation
  • If using fuse‑overlayfs, apply the same restriction or backport the kernel patch to the userspace daemon
  • Limit write access to OverlayFS mount points by configuring stricter file permissions, user namespaces, or by disabling OverlayFS in the kernel configuration when it is not needed

Generated by OpenCVE AI on September 15, 2026 at 21:54 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sat, 03 Oct 2026 11:15:00 +0000


Mon, 14 Sep 2026 12:30:00 +0000


Sun, 13 Sep 2026 06:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 5.3, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H'}

cvssV3_1

{'score': 8.4, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H'}


Sat, 12 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-1220
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.3, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H'}

threat_severity

Moderate


Fri, 11 Sep 2026 23:45:00 +0000

Type Values Removed Values Added
Description 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]
Title landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-03T10:56:34.543Z

Reserved: 2026-09-11T19:38:34.725Z

Link: CVE-2026-89560

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-11T20:19:39.803

Modified: 2026-10-03T11:17:42.840

Link: CVE-2026-89560

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-11T19:44:32Z

Links: CVE-2026-89560 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-15T22:00:17Z

Weaknesses
  • CWE-1220

    Insufficient Granularity of Access Control