Answer in brief
CVE-2026-89674 records a Unknown severity vulnerability in nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget. 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 | >=9b9960a0ca4773e21c4b153ed355583946346b25 <e7d9d23ecd9172f05b09bb678ff22db8e361c428 || >=9b9960a0ca4773e21c4b153ed355583946346b25 <0380129b1373c437eb35401a174671c8888f4b80 || >=9b9960a0ca4773e21c4b153ed355583946346b25 <c81cef6a805dec266c10fc4f83c93d6fcf1a2b43 || >=9b9960a0ca4773e21c4b153ed355583946346b25 <f9868174af49d207fbaf0c5e055d088a983684af | e7d9d23ecd9172f05b09bb678ff22db8e361c428, 0380129b1373c437eb35401a174671c8888f4b80, c81cef6a805dec266c10fc4f83c93d6fcf1a2b43, f9868174af49d207fbaf0c5e055d088a983684af |
| Linux/Linuxgeneric | 4.8 | Not reported |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 11, 2026
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use "8 + len" but xdr_encode_opaque() actually writes "4 + xdr_align_size(len)" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.
Quoted source text, attributed separately from HOL analysis.