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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:55.773Z",
  "pubdate": "2026-09-11T20:19:55.773Z",
  "executiveSummary": "A reference counting vulnerability exists in the Linux kernel nfsd component during the replay of stateid operations.\nThe vulnerability involves an incorrect decrement of a stateowner reference count when a retry occurs due to an -EAGAIN error, leading to a stateowner refcount underflow.\nThis flaw can result in use-after-free conditions and memory corruption within the kernel.\nThe issue specifically impacts the nfsd4_preprocess_seqid_op function, where a reference held on a state identifier (stid) is incorrectly ignored while an unheld reference to a stateowner is erroneously released.\nExploitation of this vulnerability could lead to kernel-level memory corruption, system instability, or potential denial-of-service (DoS) conditions due to leaked stid references stalling state management processes.\nThe vulnerability is triggered during specific NFSv4 protocol interaction sequences involving replay retries, requiring an attacker to have the ability to interact with the NFS server.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper management of reference counting within the nfsd4_preprocess_seqid_op function in the Linux kernel's nfsd implementation. In this function, a state identifier (stid) is retrieved via nfsd4_lookup_stateid(), which increments the sc_count reference on the stid. However, no corresponding reference is taken on the stateowner object.\nWhen the function encounters a condition requiring a replay retry—specifically when nfsd4_cstate_assign_replay() returns -EAGAIN—it indicates that the stateowner is currently being torn down (RP_UNHASHED). In the existing implementation, the error handling path incorrectly calls nfs4_put_stateowner(stp->st_stateowner). This action performs a premature decrement on a reference that was never formally acquired for this specific execution flow.\nThis imbalance creates two primary technical issues: First, the premature release of the stateowner reference triggers a refcount underflow, which can lead to a use-after-free (UAF) scenario if the stateowner object is freed while still referenced elsewhere. Second, the stid reference (sc_count) is leaked because the function fails to drop the reference it actually holds before exiting or retrying.\nThe leaked stid reference has significant side effects, most notably stalling concurrent operations such as nfsd4_close_open_stateid(). Because the close operation waits for the sc_count to drop to zero to safely finalize the state teardown, the leaked reference acts as a persistent block, resulting in a localized denial-of-service or deadlock for related NFSv4 state operations.\nThe exploitation path involves a remote client initiating an NFSv4 state operation that triggers the replay logic during a race condition with concurrent state teardown. By repeatedly inducing this -EAGAIN condition, an attacker can manipulate the internal kernel refcounting, leading to kernel heap corruption or forcing the system into an unstable state. Given that NFS is typically exposed over the network, this vulnerability presents a pathway for authenticated or sometimes unauthenticated users to influence kernel memory integrity.\nSuccessful exploitation requires the attacker to understand the timing of the nfsd state machine. By precisely timing requests that force the nfsd4_cstate_assign_replay() retry, the attacker can influence the lifecycle of the stateowner and stid objects, ultimately leading to exploitation of the kernel's memory management subsystems."
}