AI analysis
The Linux kernel's NFS server (nfsd) contains a reference-counting flaw in nfs4_preprocess_seqid_op(): on a replay retry where nfsd4_cstate_assign_replay() returns -EAGAIN because the replay stateowner is being torn down, the error path drops a stateowner reference it never acquired, risking a stateowner refcount underflow and use-after-free in kernel memory. The bug also leaks the stateid (stid) reference, which can stall concurrent close operations waiting on that refcount. A remote attacker who can act as an NFSv4 client to the server can trigger this path with crafted or replayed seqid operations, potentially achieving kernel memory corruption (privilege escalation or code execution in kernel context) or a denial-of-service crash/hang of the NFS service. Any Linux system exporting filesystems over NFSv4 with a vulnerable kernel is affected; there is no evidence of exploitation in the wild and no public proof of concept.
What to do: Patch to a kernel release containing the upstream nfsd fix as soon as your distribution ships it, and prioritize NFS file servers and NAS appliances running nfsd. As mitigation, restrict access to TCP/2049 with firewall rules so only trusted client networks can reach NFS exports, and consider disabling NFSv4 exports on hosts that do not need them. Monitor for nfsd crashes, oopses, or hung CLOSE operations, which are indicative symptoms of this bug.
Affected
| Linux kernel (nfsd / NFSv4 server) | — |
Estimated exposure
largeTens of thousands of internet-exposed NFS endpoints (port 2049), plus plausibly millions of NFS-serving Linux hosts on internal enterprise and HPC networks — Public internet scans of TCP/2049 typically show on the order of tens of thousands of exposed NFS servers, while NFS remains a pervasive internal file-sharing layer in enterprises, so total deployment is far larger than the…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
In the Linux kernel, the following vulnerability has been resolved: nfsd: drop the stateid, not the stateowner, on seqid_op replay retry In nfs4_preprocess_seqid_op() the stateid is obtained from nfsd4_lookup_stateid(), which holds a reference on the nfs4_stid (sc_count) but takes no reference on the stateowner. openlockstateid() merely casts that stid and likewise takes no reference. When nfsd4_cstate_assign_replay() returns -EAGAIN (the replay owner is being torn down, RP_UNHASHED) it has not taken a stateowner reference on that path. The error handling nevertheless called nfs4_put_stateowner(stp->st_stateowner), dropping an so_count reference the function never acquired -- risking a stateowner refcount underflow and use-after-free -- while leaking the sc_count reference held on the stid. The leaked stid reference can also stall a concurrent nfsd4_close_open_stateid() waiting for sc_count to drop. Drop the reference actually held -- the stid -- before retrying. The stateowner stays alive through the reference held by the stid. This mirrors the open path in nfsd4_process_open1(), where the put balances a reference that path explicitly holds on the stateowner.