CVE-2026-89538: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field
gsskrb5unwrapv2() sets buf->len to a logical length, which can be much smaller than head[0].iovlen (the allocated receive-page capacity). It then calls xdrbuftrim() 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 xdrbuftrim() 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 xdrbuftrim(), giving callers a well-defined GSSSDEFECTIVETOKEN error and keeping the xdrbuf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaquelen -- 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 xdrbuftrim() cuts into the bytes ahead of the blob.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Implement the fix described: reject Kerberos v2 wrap tokens when the 'extra count' (ec) field in the token header is oversized before calling xdr_buf_trim(), returning a well-defined GSS_S_DEFECTIVE_TOKEN error.
Linux kernel SUNRPC (krb5 v2 wrap tokens) Reject oversize ec field in Kerberos v2 token header = enabled
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs to be a peer that holds a valid Kerberos GSS context. Random mutation of the token's extra-count field is rejected because that field is authenticated.
Are malformed tokens rejected after the fix?
Yes. Kerberos v2 wrap tokens whose 16-bit extra-count field exceeds the plaintext length are rejected with GSS_S_DEFECTIVE_TOKEN before buffer trimming occurs.
What is the impact of an oversized extra-count field before the fix?
The receive buffer can be left in a semantically invalid state, with zero logical length and inconsistent I/O vector lengths. The issue does not rely on unsigned-underflow behavior because trimming clamps that subtraction.