Answer in brief
CVE-2026-90234 records a Unknown severity vulnerability in NFS: Return a delegation the client fails to record. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ade04647dd56881e285983af3db702d56ee97e86 <92533e49fe3c455088657b862cf3562260c0ce25 || >=ade04647dd56881e285983af3db702d56ee97e86 <220af23d863995091f0edeb1e6aa0945b3db8b37 | 92533e49fe3c455088657b862cf3562260c0ce25, 220af23d863995091f0edeb1e6aa0945b3db8b37 |
| Linux/Linuxgeneric | 4.0 | Not reported |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
In the Linux kernel, the following vulnerability has been resolved: NFS: Return a delegation the client fails to record When an NFS server grants a delegation in an OPEN reply, nfs_inode_set_delegation() records it on the client. However, three of its error flows return without sending DELEGRETURN. A delegation can be relinquished only by DELEGRETURN (RFC 8881 Section 20.2.4), so dropping one silently leaves the server believing the client still holds it. If the server happens to recall that delegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE because it has no record of the stateid. The server revokes the delegation and moves it onto its cl_revoked list, because the client never sends the FREE_STATEID that would drain it. Every subsequent SEQUENCE reply then carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the client's state manager loops issuing TEST_STATEID across its delegations without ever clearing the condition. The window is easy to reach now that a server offers a write delegation on any write OPEN: a delegation recalled for one opener races a re-open that the server answers with a fresh write delegation. Instead of dropping it, hand the delegation back during these error flows.
Quoted source text, attributed separately from HOL analysis.