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