CVE-2026-89541

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