Description

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token minimum length").

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:37.247Z",
  "pubdate": "2026-09-11T20:19:37.247Z",
  "executiveSummary": "The Linux kernel's SUNRPC implementation contains an integer overflow vulnerability in the gss_unwrap_resp_priv function, leading to potential out-of-bounds (OOB) memory access.\nThe vulnerability arises from improper validation of the RPCSEC_GSS opaque length field, which is susceptible to integer wrapping when added to the offset within the receive buffer.\nAn unauthenticated or remote attacker acting as a malicious krb5p NFS server can transmit a specially crafted RPCSEC_GSS reply to trigger this overflow.\nSuccessful exploitation allows an attacker to bypass bounds checking, leading to out-of-bounds reads in gss_krb5_unwrap_v2 and subsequent memory processing loops.\nThe impact includes potential information disclosure or kernel-level memory corruption. This issue highlights the danger of unchecked arithmetic operations when processing network-supplied length fields in kernel space.",
  "technicalDetails": "The root cause of this vulnerability is the unsafe summation of an 'offset' and an 'opaque_len' variable within gss_unwrap_resp_priv, where both operands are treated as unsigned 32-bit integers. The original validation logic performed a check 'offset + opaque_len > rcv_buf->len'. By providing a sufficiently large 'opaque_len' value (near 0xffffffff), an attacker causes the addition to wrap around to a small value, effectively bypassing the bounds check.\nFurthermore, the function lacked a lower-bound validation for 'opaque_len'. RFC 4121 requires a minimum outer token length; however, the code accepted any length less than GSS_KRB5_TOK_HDR_LEN. This allows an attacker to pass maliciously small values that are forwarded to gss_krb5_unwrap_v2().\nIn the vulnerable function gss_krb5_unwrap_v2(), the code performs a pre-decrypt header read using pointers derived from 'ptr+4' and 'ptr+6'. Because the length check failed to account for the minimum structure size, these pointers move past the intended buffer boundaries, leading to out-of-bounds reads when the code accesses the memory address.\nThe attack flow begins when a client receives a crafted RPCSEC_GSS reply from an NFS server. The kernel, assuming the reply is legitimate, invokes gss_unwrap_resp_priv. The malicious 'opaque_len' triggers the integer wrap, causing the check to return a false 'safe' status. The function then calls gss_unwrap(), providing an 'end' parameter that is logically smaller than the 'begin' parameter. Once inside the processing loop, the kernel performs out-of-bounds reads during the krb5 token unwrapping and subsequent rotate_left operations. This can expose sensitive kernel stack memory or trigger kernel panics, depending on the memory layout and the nature of the OOB read."
}