CVE-2026-89688: nfsd: drop the stateid, not the stateowner, on seqid_op replay retry
In the Linux kernel, the following vulnerability has been resolved:
nfsd: drop the stateid, not the stateowner, on seqidop replay retry
In nfs4preprocessseqidop() the stateid is obtained from nfsd4lookupstateid(), which holds a reference on the nfs4stid (sccount) but takes no reference on the stateowner. openlockstateid() merely casts that stid and likewise takes no reference.
When nfsd4cstateassignreplay() returns -EAGAIN (the replay owner is being torn down, RPUNHASHED) it has not taken a stateowner reference on that path. The error handling nevertheless called nfs4putstateowner(stp->ststateowner), dropping an socount reference the function never acquired -- risking a stateowner refcount underflow and use-after-free -- while leaking the sccount reference held on the stid. The leaked stid reference can also stall a concurrent nfsd4closeopenstateid() waiting for sccount 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 nfsd4processopen1(), where the put balances a reference that path explicitly holds on the stateowner.
Affected Software
Event History
Frequently Asked Questions
Under what condition is the affected error path reached?
It is reached when nfsd4_cstate_assign_replay() returns -EAGAIN because the replay owner is being torn down and is marked RP_UNHASHED.
What impact can this have on an NFS server?
The incorrect reference release can cause a stateowner reference-count underflow and use-after-free. It also leaks a stateid reference, which can block a concurrent nfsd4_close_open_stateid() operation while it waits for sc_count to drop.