CVE-2026-89550: SUNRPC: svcauth_gss: enforce krb5 token minimum length
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: svcauthgss: enforce krb5 token minimum length
svcauthgssunwrappriv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gssunwrap():
if (len > xdrstreamremaining(xdr)) goto unwrapfailed; offset = xdrstreampos(xdr); ... majstat = gssunwrap(ctx, offset, offset + len, buf);
The wire value len flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gssunwrap(). For a krb5 v2 context that lands in gsskrb5unwrapv2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotateleft() before any integrity check. With a sub-header length the header reads run past the token, and rotateleft()'s shift %= buf->len path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotateleft() builds a zero-length subbuffer, reaching the same division.
Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload.
Fix by adding a minimum-length check immediately after the existing upper-bound check:
if (len <= GSSKRB5TOKHDRLEN) goto unwrapfailed;
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix for SUNRPC svcauth_gss: reject the received GSS-KRB5 sealed RFC 4121 token at the server entry point before it reaches the unwrap path by enforcing a minimum token length check (the fix covers rejecting header-only tokens with len <= GSS_KRB5_TOK_HDR_LEN, including len in [0, 16], prior to calling into gss_unwrap/gss_krb5_unwrap_v2).
Linux kernel SUNRPC svcauth_gss enforce krb5 token minimum length = reject tokens with len in [0, 16] at server entry point
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Linux kernel systems acting as SUNRPC servers and processing RPCSEC_GSS privacy-wrapped traffic with Kerberos v5 contexts are exposed. The vulnerable path is server-side svcauth_gss_unwrap_priv().
What does an attacker need to send to trigger the flaw?
An attacker needs to supply a malformed Kerberos v5 privacy token whose wire-supplied opaque length is 16 bytes or less. A 16-byte header-only token with a non-zero RRC field can also reach the divide-by-zero condition when the blob ends at the XDR buffer boundary.
Is a valid integrity check required before the vulnerable operation occurs?
No. The truncated token can reach the Kerberos unwrap and rotation logic before integrity validation, allowing the zero-length buffer condition to occur first.
What is the remediation indicated by the available information?
Apply a Linux kernel update containing the referenced fixes. The fix rejects undersized Kerberos tokens at the server entry point before they reach the unwrap path.