In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv

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

 1offset = (u8 *)(p) - (u8 *)head->iov_base;
 2if (offset + opaque_len > rcv_buf->len)
 3        goto unwrap_failed;
 4maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset,
 5                      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:

 1if (offset > rcv_buf->len)
 2        goto unwrap_failed;
 3if (opaque_len > rcv_buf->len - offset)
 4        goto unwrap_failed;
 5if (opaque_len < GSS_KRB5_TOK_HDR_LEN)
 6        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").