CVE-2026-89551
moderateInteger underflow in Linux kernel SUNRPC xdr_buf_trim via Kerberos GSS unwrap
The Linux kernel's SUNRPC xdr_buf_trim() helper subtracts trimmed bytes from buf->len without clamping, so when a caller (notably gss_krb5_unwrap_v2(), which handles unwrapping of Kerberos-wrapped RPCSEC_GSS v2 tokens) sets buf->len to a small wire-derived value while the iovec lengths are page-scale, the unsigned subtraction wraps buf->len to near UINT_MAX. An attacker who can send an RPC request carrying a crafted GSS Kerberos token to an NFS server (or peer) using krb5i/krb5p-style integrity/privacy protection triggers the underflow, and the bogus huge length is then used as the authoritative bound by every downstream XDR decoder. That corrupted length bound can drive out-of-bounds kernel memory access, plausibly crashing the kernel (denial of service) or enabling kernel memory corruption with confidentiality, integrity, and availability impact — reflected in the critical 9.8 network-vector rating that requires no privileges or user interaction, though reaching the vulnerable path generally implies possession of a usable Kerberos credential against the target. Affected systems are Linux machines running kernels prior to the upstream fix where SUNRPC and Kerberos GSS (AES-based krb5 tokens) are in use, chiefly NFS servers and clients enforcing sec=krb5i/krb5p. No public proof of concept is known and the flaw is not listed in CISA's KEV, so exploitation in the wild appears unlikely at this time.
What to do: Update to a kernel release containing the upstream fix (xdr_buf_trim now clamps the decrement so buf->len bottoms out at zero) as soon as your distributor ships it, prioritizing NFS file servers with Kerberos-secured exports. In the interim, restrict TCP/UDP 2049 and the RPC ports to trusted clients and networks with firewall rules, and audit exports for sec=krb5i/krb5p mounts since those are the vulnerable code path. Watch for kernel oops/panic reports in the sunrpc or gss_krb5 paths as a sign of probing.
| Linux kernel (net/sunrpc: xdr_buf_trim / gss_krb5_unwrap_v2) | — |
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: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always len and the result is identical to before. No callers change behavior outside the underflow case.
- 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.