CVE-2026-89541: SUNRPC: harden gss_unwrap_resp_priv length checks

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

SUNRPC: harden gssunwrapresppriv length checks

gssunwrapresppriv() validates the RPCSECGSS opaque length with

offset = (u8 )(p) - (u8 )head->iovbase; if (offset + opaquelen > rcvbuf->len) goto unwrapfailed; 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 rcvbuf->len, so the bound check passes and gssunwrap() is called with end < begin. The check also lacks a lower bound, so any opaquelen in [0, GSSKRB5TOKHDRLEN) is accepted and forwarded to gsskrb5unwrapv2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token.

A krb5p NFS server returning a crafted RPCSECGSS reply can drive the client into out-of-bounds reads in gsskrb5unwrapv2() and the rotateleft() 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 > rcvbuf->len) goto unwrapfailed; if (opaquelen > rcvbuf->len - offset) goto unwrapfailed; if (opaquelen < GSSKRB5TOKHDRLEN) goto unwrapfailed;

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: svcauthgss: enforce krb5 token minimum length").