CVE-2026-89541

In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: harden gssunwrapresp_priv length checks

gssunwrapresppriv() validates the RPCSECGSS opaque length with

    offset = (u8 )(p) - (u8 )head->iov_base;

    if (offset + opaquelen > rcvbuf->len)

            goto unwrap_failed;

    majstat = gssunwrap(ctx->gcgssctx, offset,

                          offset + opaquelen, rcvbuf);

Both operands are u32 and the sum is computed in u32. A reply with

opaquelen near 0xffffffff makes offset + opaquelen 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 opaquelen in [0, GSSKRB5TOKHDR_LEN) is

accepted and forwarded to gsskrb5unwrap_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 gsskrb5unwrap_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 (opaquelen > rcvbuf->len - offset)

            goto unwrap_failed;

    if (opaquelen < GSSKRB5TOKHDR_LEN)

            goto unwrap_failed;

The first guard makes the subtraction in the second guard

unconditionally safe; offset is derived from a successful

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