CVE-2026-89674
nicheOut-of-bounds write and kernel memory leak in Linux kernel nfsd flexfiles XDR encoding
The Linux kernel's NFS server (nfsd) miscalculates the XDR buffer size in nfsd4_ff_encode_layoutget() when encoding pNFS flexible-file (flexfiles) layoutget responses, due to missing padding on file handle data, wrong uid/gid length math, and mismatched header constants. An NFS client that triggers a layout request can cause the kernel to write up to 5 bytes past the reserved buffer (out-of-bounds write) in the worst case, or receive stale, uninitialized kernel memory when string lengths happen to be 4-byte aligned. Successful exploitation could corrupt kernel memory, potentially crashing or compromising the server, or disclose sensitive kernel data to the client. Only systems running the kernel's nfsd and actually serving pNFS flexfiles layouts to clients are affected; standard non-pNFS NFS exports are not. The issue carries a critical 9.8 CVSS score, but there is no known public PoC and no evidence of in-the-wild exploitation.
What to do: Patch to a kernel release containing the nfsd4_ff_encode_layoutget fix as soon as your distribution ships it. If pNFS flexfiles layouts are not required, disable flexfiles layout serving (avoid ff layout exports) to remove the vulnerable code path immediately. Restrict NFS access to trusted clients via exports and firewall rules on port 2049, and verify no untrusted networks can reach your NFS services.
| Linux kernel (nfsd, nfsd4_ff_encode_layoutget / pNFS flexfiles layout encoding) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.