GPU VulnDB

Database/Control plane, storage & DevOps

Linux nfsd: seqid_op replay retry drops a stateowner reference it never took

CVSS 9.8CVE-2026-89688Control plane, storage & DevOpscurated

Impact

When nfsd4_cstate_assign_replay() returns -EAGAIN because the replay owner is being torn down, the error path called nfs4_put_stateowner() on a so_count reference it never acquired, while leaking the sc_count reference it did hold on the stid. That risks a stateowner refcount underflow and use-after-free in the NFS server, and the leaked stid reference can stall a concurrent nfsd4_close_open_stateid() waiting for the count to drop - a hung CLOSE that looks like a storage stall to every client. Driving it requires hitting the narrow window where a replay owner is unhashed, which makes it hard to aim but reachable from ordinary client traffic on a busy export.

Who can reach it

Any NFSv4 client permitted to mount the export and issue seqid-bearing operations (OPEN/LOCK/CLOSE) concurrently. Standard client authentication only.

What to do

Update the NFS server kernel to include one of the linked stable commits and reboot; the fix drops the stid reference instead of the stateowner. No runtime mitigation exists - nfsd is in-kernel, so restarting the service does not carry the fix.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.