CVE-2026-89538
largeMalformed Kerberos v2 wrap token handling in Linux kernel SUNRPC/GSS
The Linux kernel's RPC GSS layer (gss_krb5_unwrap_v2) fails to reject Kerberos v2 wrap tokens whose 16-bit 'extra count' (ec) field exceeds the plaintext length, which RFC 4121 defines as structurally malformed. Because the trim-length check compares against the whole receive buffer rather than the wrapped segment that starts at a nonzero offset, an oversized ec can slip through and xdr_buf_trim() then cuts into bytes ahead of the blob, leaving the buffer with zero length and inconsistent iovec lengths. A remote attacker who holds a valid GSS context (for example, a Kerberos-authenticated NFS client or any peer able to complete krb5 negotiation over RPC) can send a crafted token to corrupt kernel RPC receive buffers, plausibly causing a crash or worse; this severity is reflected in the critical 9.8 CVSS rating. Any Linux kernel deployment using Kerberos-secured RPC, most commonly NFS mounted with sec=krb5i or sec=krb5p, is affected. No public proof of concept or in-the-wild exploitation is known, and the flaw is not on the CISA KEV list.
What to do: Apply your distribution's kernel update once the upstream SUNRPC fix (rejecting oversized-ec tokens with GSS_S_DEFECTIVE_TOKEN before trimming) is backported, and reboot or reload affected hosts. In the interim, audit NFS exports and RPC services for sec=krb5i/krb5p usage and restrict which Kerberos principals and client machines are permitted to establish GSS contexts with servers, since exploitation requires a valid context. Monitor for repeated GSS unwrap failures or crashes in the NFS/RPC receive path on krb5-protected mounts.
| Linux kernel (SUNRPC / gss_krb5 gss unwrap) | — |
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: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit "extra count" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.
- 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.