Look up another CVE · open CVE-2026-89560 in the interactive tracker
CVE-2026-89560
landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem include/uapi. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89560 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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]
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/uapi/linux/landlock.h
security/landlock/errata/abi-1.h
security/landlock/fs.c
- What this is
- LANDLOCK SECURITY MODULEMAINTAINERS section matched on include/uapi/linux/landlock.h · linux-security-module@vger.kernel.org · Supported
Check it on the machine
grep -w CONFIG_SECURITY_LANDLOCK /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_SECURITY_LANDLOCK
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 8.4 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/uapi
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.13 | 5.15.222 | 39fc16597715 |
| 5.13 | 6.1.188 | d739e3231847 |
| 5.13 | 6.6.157 | dfb10d989056 |
| 5.13 | 6.12.110 | efb4f24fc2b9 |
| 5.13 | 6.18.50 | 627ce4902df1 |
| 5.13 | 7.2.4 | 0c3204aacbe8 |
| 5.13 | 7.3 | 672fa082d48b |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bypass is reached only via local renameat2(RENAME_WHITEOUT) on a writable filesystem (tmpfs, ext4, btrfs, xfs, f2fs); Landlock's hook_path_rename runs on that syscall with no network, Bluetooth, or physical entry point.
- AC:LAttack complexity, low
- The attacker triggers whiteout creation deterministically by renaming a file whose MAKE type is allowed or unhandled (the selftest uses a FIFO while MAKE_REG is denied); tmpfs supports RENAME_WHITEOUT and no race, layout, or rare config is required.
- PR:LPrivileges required, low
- Only an ordinary local user in a Landlock domain is needed; vfs_mknod() exempts WHITEOUT_DEV from CAP_MKNOD, vfs_rename() never checks it, and landlock_restrict_self() is unprivileged via no_new_privs or CAP_SYS_ADMIN in a user namespace.
- UI:NUser interaction, none
- The confined process issues renameat2(RENAME_WHITEOUT) itself; no separate victim action such as mounting a filesystem or opening a crafted file is required.
- S:CScope, changed
- The missing MAKE_* check bypasses the Landlock sandbox, letting a confined task create OverlayFS whiteout objects in directories the policy forbade creation in, affecting filesystem resources under a separate security authority as in other Landlock policy-bypass CVEs.
- C:NConfidentiality impact, none
- Creating a char 0:0 whiteout does not read kernel or victim memory, leak pointers, or grant Landlock READ_FILE/READ_DIR rights; WHITEOUT_DEV is not bound to a driver and opening it yields no disclosure primitive.
- I:HIntegrity impact, high
- A sandboxed attacker can create OverlayFS whiteout directory entries even when all LANDLOCK_ACCESS_FS_MAKE_* rights are denied, planting char 0:0 objects that hide or replace lower-layer names in an overlay upperdir and fully defeating the file-creation policy.
- A:HAvailability impact, high
- OverlayFS treats planted whiteouts as deletions in the unified view, so matching lower-layer files become completely inaccessible to every consumer of that overlay, which is a total loss of availability for those protected resources.