Look up another CVE · open CVE-2026-74343 in the interactive tracker
CVE-2026-74343
kernfs: fix xattr race condition with multiple superblocks
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/kernfs. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-74343 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
Multiple superblocks with different namespaces can share the same kernfs_node when kernfs_test_super() finds a matching root but different namespace. This means multiple inodes from different superblocks can reference the same kernfs_node->iattr->xattrs structure. The VFS layer only holds per-inode locks during xattr operations, which is insufficient to serialize concurrent xattr modifications on the shared kernfs_node. This can lead to race conditions in simple_xattr_set() where the lookup->replace/remove sequence is not atomic with respect to operations from other superblocks. Fix this by protecting xattr operations with the existing hashed kernfs_locks->open_file_mutex[] array, which is already used to protect per-node open file data. The hashed mutex array provides scalable per-node serialization (scaled by CPU count, up to 1024 locks on 32+ CPU systems) with zero memory overhead. Changes: - Rename open_file_mutex[] to node_mutex[] to reflect dual purpose - Add kernfs_node_lock_ptr() and kernfs_node_lock() helpers - Protect simple_xattr_set() calls in kernfs_xattr_set() and kernfs_vfs_user_xattr_set() with the hashed mutex - Update file.c to use new helpers via compatibility wrappers - Update documentation to explain the extended lock usage
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/kernfs/file.c
fs/kernfs/inode.c
fs/kernfs/kernfs-internal.h
fs/kernfs/mount.c
include/linux/kernfs.h
- What this is
- KERNFSMAINTAINERS section matched on fs/kernfs/ · driver-core@lists.linux.dev · Supported
Check it on the machine
grep -w CONFIG_KERNFS /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, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_KERNFS
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-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.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/kernfs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.1 | 7.1.5 | bf53db513599 |
| 7.1 | 7.2 | 6a07814ff643 |
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 bug is reached only through local VFS xattr operations (setxattr/fsetxattr syscalls) on kernfs-backed mounts such as cgroup2 and sysfs; there is no network-facing handler or remote pre-auth path to the vulnerable code.
- AC:LAttack complexity, low
- The attacker fully controls both racing threads by mounting the same kernfs hierarchy from different namespace-tagged superblocks (e.g. sysfs in two network namespaces) and issuing concurrent setxattr calls against the same shared kernfs_node.
- PR:LPrivileges required, low
- Exploitation requires only local user capabilities obtainable in an unprivileged user namespace (CAP_SYS_ADMIN to create namespaces and mount cgroup2/sysfs), not init-namespace root or host administrator privileges.
- UI:NUser interaction, none
- No victim interaction is required; the attacker mounts the filesystems, selects the target kernfs_node, and triggers the race with their own concurrent setxattr operations.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption and privilege escalation within the same kernel/host security boundary; this is not a VM escape, sandbox breakout, or cross-authority scope change.
- C:HConfidentiality impact, high
- Concurrent unsynchronized simple_xattr_set() on a shared rhashtable/list can cause use-after-free and heap corruption, which is readily weaponizable for arbitrary kernel memory disclosure, not merely a bounded leak.
- I:HIntegrity impact, high
- The race corrupts shared xattr rhashtable and list structures, enabling use-after-free and heap metadata corruption that can be leveraged for arbitrary kernel writes and local privilege escalation/code execution.
- A:HAvailability impact, high
- The race can trigger kernel oops/panic from list/rhashtable corruption or use-after-free during concurrent replace/remove/free paths, causing complete loss of kernel availability even without full exploitation.