Look up another CVE · open CVE-2026-72368 in the interactive tracker

CVE-2026-72368

cachefiles: Fix double unlock in nomem_d_alloc error path

7.8 EPSS 0.2% AV:L

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/cachefiles. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-72368 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	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.1.5-1	Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.5-1	Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

When start_creating() fails and returns -ENOMEM, it has already released the parent directory lock in __start_dirop(): static struct dentry *__start_dirop(...) { ... inode_lock_nested(dir, I_MUTEX_PARENT); dentry = lookup_one_qstr_excl(name, parent, lookup_flags); if (IS_ERR(dentry)) inode_unlock(dir); <-- Lock released on error return dentry; } However, the nomem_d_alloc error path in cachefiles_get_directory() unconditionally calls inode_unlock(d_inode(dir)) again, causing a double unlock that corrupts the rwsem state. This is a leftover from commit 7ab96df840e60 which replaced manual locking with start_creating() but failed to update the nomem_d_alloc path (while correctly updating mkdir_error and lookup_error paths).

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.

fs/cachefiles/namei.c

What this is: CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMSMAINTAINERS section matched on fs/cachefiles/ · netfs@lists.linux.dev · Supported
Kernel module: cachefiles

Check it on the machine

grep -w CONFIG_CACHEFILES /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.

lsmod | grep -w cachefiles

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

bookworm, trixie, forky, sidm

m: a loadable module on every flavour - check lsmod, can be blacklisted

Build switch: CONFIG_CACHEFILES

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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-15 (2 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.17%, higher than 5.4% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: fs/cachefiles

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.19	7.1.5	26757dac1517
6.19	7.2	8c256fba2b46

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 flaw is in cachefiles VFS directory creation reached only via local `/dev/cachefiles` ioctl/bind or local NFS/CIFS/9p fscache volume setup during mount, not from remote packet handling like nfsd or ksmbd.
AC:LAttack complexity, low: Triggering requires only a `-ENOMEM` from `start_creating()` during `cachefiles_get_directory()`, which an attacker can reliably force with local memory pressure or repeated bind/mount attempts; no uncontrollable race or rare layout is needed once CACHEFILES is active.
PR:LPrivileges required, low: Exploitation needs `CAP_SYS_ADMIN` to open `/dev/cachefiles` and bind the cache, or to mount a network filesystem with fscache while cachefilesd is running; both are obtainable in an unprivileged user namespace, not solely init-namespace root.
UI:NUser interaction, none: No separate victim action is required beyond attacker-controlled local steps (opening `/dev/cachefiles`, binding, or mounting with fscache under memory pressure); cachefilesd does not need a user to click or open a file.
S:UScope, unchanged: Corrupting a backing-directory inode rwsem affects kernel/VFS locking within the same host security boundary and does not cross VM, IOMMU, or container hypervisor isolation by itself.
C:HConfidentiality impact, high: Double-unlocking the parent directory rwsem corrupts kernel lock state and can leave the inode lock inconsistent, enabling concurrent VFS access and memory corruption primitives that may disclose kernel memory under kernel guidance for lock corruption bugs.
I:HIntegrity impact, high: Rwsem corruption breaks directory serialization, allowing unsynchronized create/lookup/mkdir operations on cache backing storage and creating conditions for further VFS metadata corruption or control-flow manipulation consistent with high integrity impact.
A:HAvailability impact, high: An extra `inode_unlock()` on an already-released rwsem corrupts lock owner/count state and commonly produces DEBUG_RWSEMS warnings, oopses, or kernel panics, matching high availability impact for kernel crash bugs.