Description

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2 gss_krb5_verify_mic_v2() reads the token ID at ptr[0..1], the flags byte at ptr[2], and padding at ptr[3..7], then passes ptr + GSS_KRB5_TOK_HDR_LEN and cksum_len to gss_krb5_mic_build_sg(). None of these accesses check read_token->len first. The minimum safe token size is GSS_KRB5_TOK_HDR_LEN (16) plus ctx->krb5e->cksum_len (12-24, depending on the enctype). All callers accept shorter tokens from the wire: - gss_unwrap_resp_integ() enforces only an upper bound (offset + len <= rcv_buf->len) before allocating mic.data = kmalloc(len) and passing it to gss_verify_mic(). A malicious NFS server can therefore supply a short checksum opaque, producing a small slab allocation that the Kerberos MIC verifier reads past. - gss_validate() enforces only len <= RPC_MAX_AUTH_SIZE (400) before passing the wire-supplied length to gss_validate_seqno_mic(), which constructs a mic xdr_netobj and calls gss_verify_mic(). - svcauth_gss_verify_header() enforces only checksum.len >= XDR_UNIT (4 bytes) before dispatching to gss_verify_mic(). - svcauth_gss_unwrap_integ() checks only that the checksum fits in gsd->gsd_scratch. Add a length guard at the top of gss_krb5_verify_mic_v2(), before any ptr[] access or scatterlist construction. Well-formed MIC tokens from gss_krb5_get_mic_v2() already have exactly GSS_KRB5_TOK_HDR_LEN + cksum_len bytes, so valid traffic is unaffected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-11T20:19:36.733Z",
  "pubdate": "2026-09-11T20:19:36.733Z",
  "executiveSummary": "This vulnerability involves an out-of-bounds (OOB) memory read within the Linux kernel's SUNRPC implementation, specifically affecting the gss_krb5_verify_mic_v2 function.\nThe flaw stems from insufficient input validation of the Kerberos MIC (Message Integrity Check) token length during GSS-API operations.\nA malicious actor, such as a compromised or adversarial NFS server, can supply a specially crafted, truncated MIC token that bypasses existing size checks.\nThe primary impact is a potential OOB memory read, which can lead to information disclosure or system instability (kernel panic).\nExploitation requires the attacker to be in a position to influence the RPC communication intercepted by the target kernel, specifically leveraging the interaction between the network-supplied token length and the subsequent kernel heap allocation.\nSystems utilizing Kerberos-based RPC authentication are at risk, and the vulnerability affects the protocol handling layer of the Linux kernel.",
  "technicalDetails": "The vulnerability resides in the gss_krb5_verify_mic_v2 function within the Linux kernel's SUNRPC subsystem. The kernel fails to enforce a minimum length requirement for RFC 4121 MIC tokens before accessing the token's internal headers.\nSpecifically, the function performs direct pointer arithmetic and reads on the incoming token buffer (ptr[0..7]) to extract token identifiers, flags, and padding without first verifying if the buffer length meets the required minimum of GSS_KRB5_TOK_HDR_LEN (16 bytes) plus the checksum length (12-24 bytes, depending on the enctype).\nThe root cause is the reliance on incomplete size validation across various caller functions, including gss_unwrap_resp_integ, gss_validate, svcauth_gss_verify_header, and svcauth_gss_unwrap_integ. These callers only enforce upper-bound constraints (e.g., RPC_MAX_AUTH_SIZE or buffer capacity) or insufficient lower-bound constraints (e.g., 4-byte XDR units), failing to account for the specific structure requirements of the v2 MIC token.\nIn the case of gss_unwrap_resp_integ, the process is as follows: 1) The attacker provides a short checksum opaque via the network. 2) The kernel allocates a slab buffer based on this short length. 3) The kernel passes this undersized buffer to gss_verify_mic. 4) The function, expecting a larger structure, reads past the end of the allocated slab, leading to an OOB read.\nThis attack flow permits an attacker to influence memory access patterns by controlling the length parameter. By providing a token smaller than the expected GSS_KRB5_TOK_HDR_LEN, the attacker triggers an OOB read when the kernel attempts to process the expected header bytes. This behavior facilitates the reading of kernel heap memory that follows the allocated token buffer, potentially exposing sensitive kernel data to the attacker, or forcing a segmentation fault/kernel panic by attempting to access unmapped memory regions.\nBecause the validation occurs post-allocation in several call paths, the integrity of the memory access depends entirely on the attacker-supplied length, which is not verified against the cryptographic requirements of the Kerberos MIC verification process prior to being used as an index for reading the token fields."
}