AZL-100877

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").