Look up another CVE · open CVE-2026-72472 in the interactive tracker
CVE-2026-72472
nfs: use nfsi->rwsem to protect traversal of the file lock list
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/nfs. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72472 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| 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
Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), it has been resolved after commit 0460253913e5 ("NFSv4: nfs4_do_open() is incorrectly triggering state recovery") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.
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/nfs/delegation.c
fs/nfs/nfs4proc.c
include/linux/nfs_xdr.h
- What this is
- NFS, SUNRPC, AND LOCKD CLIENTSMAINTAINERS section matched on fs/nfs/ · linux-nfs@vger.kernel.org · Maintained
- Kernel module
- nfsv4
Check it on the machine
grep -wE 'CONFIG_NFS_FS|CONFIG_NFS_V4' /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 nfsv4Prints 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 switches
- CONFIG_NFS_FS, CONFIG_NFS_V4
- Reads as
- all on means the file is compiled; any one off means it is not.
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
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.65%, higher than 50.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/nfs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.0 | 6.12.97 | 1cda95bf2e9c |
| 4.0 | 6.18.40 | f161ef7b0dd2 |
| 4.0 | 7.1.5 | e68035178e65 |
| 4.0 | 7.2 | 4837fb36219e |
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:NAttack vector, network
- The bug is in the NFSv4 client and is reachable via network-driven OP_CB_RECALL delegation callbacks and async LOCK/LOCKU RPC completions that invoke nfs_delegation_claim_locks, nfs4_lock_done, and nfs4_locku_done, not only via local flock/fcntl syscalls on a mounted export.
- AC:LAttack complexity, low
- Exploitation is a race while walking the inode lock list with flc_lock dropped; an attacker who controls or races concurrent recalls, lock RPC completions, and flock/fcntl operations on the same NFS file can reliably trigger the UAF without uncontrollable layout or rare kernel options.
- PR:NPrivileges required, none
- A malicious or compromised NFS server can send CB_RECALL and lock RPC responses over the established NFSv4 session to drive delegation return and lock-completion paths without any local account, capability, or root privileges on the victim client.
- UI:NUser interaction, none
- No victim interaction is required during exploitation once an NFSv4 mount with delegations exists; recalls and lock RPC completions are initiated by the server and client protocol handling while applications may already hold ordinary byte-range locks.
- S:UScope, unchanged
- Exploitation corrupts kernel heap file_lock state in the NFS client on the same host and enables local privilege escalation or denial of service, but does not by itself cross a VM, container, or IOMMU security boundary to another authority.
- C:HConfidentiality impact, high
- The flaw is a kernel heap use-after-free while iterating struct file_lock list entries; freed lock objects can be reallocated and dereferenced, enabling arbitrary kernel memory disclosure in addition to controlled corruption.
- I:HIntegrity impact, high
- UAF on file_lock structures allows attacker-influenced reuse of freed memory and can be leveraged for arbitrary kernel writes, control-flow hijacking, and privilege escalation rather than only a bounded or transient modification.
- A:HAvailability impact, high
- Concurrent lock list corruption can cause kernel oops, panic, or hang during delegation recall, state recovery, or lock RPC completion, and UAF exploitation commonly crashes the system even when used to gain code execution.