Description

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: svcauth_gss: enforce krb5 token minimum length svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap(): if (len > xdr_stream_remaining(xdr)) goto unwrap_failed; offset = xdr_stream_pos(xdr); ... maj_stat = gss_unwrap(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 gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotate_left() before any integrity check. With a sub-header length the header reads run past the token, and _rotate_left()'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, rotate_left() 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 <= GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed;

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:38.500Z",
  "pubdate": "2026-09-11T20:19:38.500Z",
  "executiveSummary": "The Linux kernel's SUNRPC (Remote Procedure Call) implementation contains a vulnerability in the svcauth_gss_unwrap_priv() function where insufficient validation of GSS-API token lengths leads to a potential kernel panic.\nThe vulnerability is triggered by providing malformed KRB5 tokens that bypass existing upper-bound checks, leading to an arithmetic error during the unwrapping process.\nThe flaw stems from a lack of minimum-length verification for tokens, allowing attackers to supply undersized buffers that result in a division-by-zero error within the gss_krb5_unwrap_v2() function.\nSuccessful exploitation of this vulnerability results in a denial-of-service (DoS) condition, as the kernel will crash when performing an invalid division operation.\nThis vulnerability is relevant to any system utilizing SUNRPC with KRB5 authentication. No authentication is required to send the malicious packet to the RPC server, making it remotely exploitable if the service is exposed to a network.\nRisk mitigation is achieved through the enforcement of stricter input validation for incoming RPC tokens.",
  "technicalDetails": "The root cause of this vulnerability lies in the svcauth_gss_unwrap_priv() function within the SUNRPC subsystem, which performs inadequate validation on wire-supplied opaque lengths during GSS-API unwrap operations.\nThe vulnerable code segment performs a bounds check against the maximum remaining XDR stream space but fails to verify if the provided 'len' parameter satisfies the minimum length requirements for a valid RFC 4121 Kerberos token.\nSpecifically, a token with a length of 16 bytes or less is processed by gss_krb5_unwrap_v2(). This function assumes the existence of a 16-byte RFC 4121 token header and attempts to perform memory operations based on this assumption.\nWhen an undersized token is processed, the code reads beyond the end of the provided buffer. Crucially, the function then invokes rotate_left() to handle the Recipient Rotation Count (RRC).\nThe rotate_left() function calculates a shift using the modulo operator against the buffer length (shift %= buf->len). When the input length is truncated or header-only, the underlying buffer representation or sub-buffer calculation results in a length of zero.\nThis triggers a division-by-zero exception within the kernel context, leading to an immediate kernel panic and system instability.\nAn attacker can exploit this by crafting a SUNRPC request with an opaque GSS token of 16 bytes or fewer. Because this processing happens before high-level integrity checks are completed, the server is forced to attempt the malformed unwrap operation.\nThe vulnerability exposes the kernel's memory management to an arithmetic fault, providing a straightforward vector for remote denial-of-service attacks against services utilizing RPCSEC_GSS, such as NFS servers.\nThe fix involves enforcing a minimum-length constraint (GSS_KRB5_TOK_HDR_LEN) immediately after the upper-bound check in svcauth_gss_unwrap_priv(), ensuring that any token smaller than the mandatory header structure is rejected before reaching the vulnerable unwrapping logic."
}