Cloudanix VulnDB

CVE-2026-89688

Critical · 9.8

CVSS

9.8

EPSS

0.7%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux file-sharing code can let remote attackers crash servers or take them over, so organizations should update their systems promptly to keep shared files safe.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect reference counting in nfs4_preprocess_seqid_op during EAGAIN replay handling drops a stateowner reference never acquired while leaking the stateid reference, enabling a use-after-free on nfs4_stateowner structures.

Why it matters to the business

Remote attackers can crash NFS servers or potentially execute arbitrary code, disrupting file-sharing services and risking full system compromise on exposed Linux hosts.

How an attack unfolds

An attacker sends crafted NFSv4 OPEN or LOCK sequences that force the server into the replay-retry path returning -EAGAIN; the unbalanced nfs4_put_stateowner call then underflows the stateowner refcount while the stid reference leak stalls close operations, leading to a freed object being reused.

How to fix it

Apply the upstream kernel patch that replaces the stateowner put with the correct stid put before retrying the seqid operation; rebuild and reboot affected systems with the corrected kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting nfsd4_preprocess_seqid_op for the stid put before the EAGAIN retry; run NFSv4 stress tests exercising replay paths and verify no refcount underflows or stalls occur.

Typical attack path

  1. Send NFSv4 compound requests containing seqid operations that trigger RP_UNHASHED replay owner teardown
  2. Force nfsd4_cstate_assign_replay to return -EAGAIN
  3. Trigger the erroneous nfs4_put_stateowner call on the unowned stateowner
  4. Reuse the freed nfs4_stateowner object via concurrent NFSv4 state operations

How to detect it

Search kernel logs and audit trails for repeated nfsd seqid replay errors followed by stateowner reference underflow warnings or use-after-free oops; correlate with NFSv4 client activity that triggers EAGAIN paths.

What your security team should do

  • Prioritize kernel updates on all systems exposing NFSv4
  • Restrict NFSv4 access to trusted clients via firewall rules until patched
  • Monitor kernel logs for stateid and stateowner reference warnings

The record

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.

Affected packages

Ecosystem Package Introduced Fixed