# CVE-2026-72472: nfs: use nfsi->rwsem to protect traversal of the file lock list

> A use-after-free vulnerability in the Linux kernel NFS subsystem allows attackers to potentially execute code or cause a denial of service.

- **Severity:** Critical 9.8 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 15 Aug 2026
- **Updated:** 16 Oct 2026
- **Also known as:** AZL-96282, BELL-CVE-2026-72472, DEBIAN-CVE-2026-72472, GHSA-r6m9-5pwq-jfm2, UBUNTU-CVE-2026-72472

## What is CVE-2026-72472?

CVE-2026-72472 is a critical use after free vulnerability in Linux, published on 15 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

nfs: use nfsi->rwsem to protect traversal of the file lock list

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.

## Which versions are affected by CVE-2026-72472?


## How do I fix CVE-2026-72472?

Apply the vendor's patch.

## Is CVE-2026-72472 being exploited?

There is no known exploitation of CVE-2026-72472 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-72472 and fix it if it is affected.

What it is: CVE-2026-72472 is a critical use after free vulnerability in Linux, published on 15 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-72472 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-72472/ (Markdown: https://insights.sbomify.com/CVE-2026-72472/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-72472
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-72472
- OSV: https://osv.dev/vulnerability/CVE-2026-72472

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-72472/
Summaries are generated and may contain mistakes; the official description above is the record.