CVE-2026-89703 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
nfsd: set SC_STATUS_FREED in nfsd4_drop_revoked_stid for delegations
nfsd4_drop_revoked_stid() handles FREE_STATEID for admin-revoked delegations but does not set SC_STATUS_FREED before releasing cl_lock. revoke_delegation() uses this flag to detect whether FREE_STATEID has already processed the delegation -- without it, the freed delegation is added to cl_revoked via list_add(), producing a use-after-free when cl_revoked is later traversed in __destroy_client().
The SC_STATUS_REVOKED path in nfsd4_free_stateid() (line 7983) already sets SC_STATUS_FREED correctly. Apply the same pattern to the SC_STATUS_ADMIN_REVOKED path in nfsd4_drop_revoked_stid().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified within the Linux kernel's NFS server implementation, specifically involving the nfsd4_drop_revided_stid function, represents a critical use-after-free condition that can lead to system instability or potential privilege escalation. This flaw occurs during the handling of FREE_STATEID operations for delegations that have been administratively revoked by an administrator. In this specific code path, the kernel fails to set the SC_STATUS_FREED flag before releasing the client lock (cl_lock). The absence of this status update creates a race condition and logical inconsistency in how the state manager tracks the lifecycle of delegation resources.
The operational impact stems from the interaction between nfsd4_drop_revoked_stid and revoke_delegation functions. When an admin revokes a delegation, the system is expected to mark it as freed so that subsequent operations recognize its invalidated state. However, because SC_STATUS_FREED remains unset in this specific path, the revoke_delegation function incorrectly assumes the FREE_STATEID operation has not yet processed the delegation. Consequently, it proceeds to add the already-freed delegation structure back into the cl_revoked list using list_add(). This action reintroduces a dangling pointer into an active data structure that is subsequently traversed by __destroy_client() during client teardown or state cleanup processes. Accessing this freed memory results in a use-after-free vulnerability, which can corrupt kernel heap structures, cause kernel panics through null pointer dereferences or invalid memory accesses, and potentially allow local attackers to execute arbitrary code with the privileges of the kernel if they can control the contents of the reclaimed memory region.
From a classification perspective, this issue aligns closely with CWE-416, Use After Free, where software continues to use a pointer after it has been freed, leading to undefined behavior and security risks. Furthermore, in the context of the MITRE ATT&CK framework for Linux systems, this vulnerability facilitates techniques related to Defense Evasion or Privilege Escalation by allowing an attacker to manipulate kernel memory state during client session teardowns. The flaw is particularly dangerous because it involves race conditions around lock release, meaning that timing attacks could potentially be leveraged to increase the window of opportunity for exploitation before the corrupted list entry causes a crash or is cleaned up.
The resolution applied in this patch corrects the oversight by ensuring that SC_STATUS_FREED is set appropriately within the nfsd4_drop_revoked_stid function when handling admin-revoked delegations. This change mirrors the existing logic found in the SC_STATUS_REVOKED path of nfsd4_free_stateid, thereby standardizing the state management across different revocation scenarios. By setting this flag before releasing cl_lock, the kernel ensures that revoke_delegation correctly identifies that the delegation has already been processed and prevents it from being re-added to the revoked list. This fix eliminates the possibility of double-freeing or use-after-free conditions during client destruction sequences.
To mitigate the risk associated with this vulnerability in environments where patching may not be immediately feasible, administrators should consider restricting access to NFS server administrative functions that trigger delegation revocations until updates are applied. Additionally, monitoring kernel logs for oops messages or panics related to nfsd components can help detect potential exploitation attempts or crashes resulting from this flaw. It is also advisable to review network segmentation policies to limit exposure of NFS servers to untrusted networks, reducing the attack surface available to local users who might attempt to trigger these state transitions through crafted RPC calls. Regularly updating the Linux kernel and associated NFS server packages remains the most effective defense against such memory corruption vulnerabilities.