CVE-2026-89551

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

SUNRPC: xdr buf trim: clamp buf->len to avoid underflow

xdr buf trim() trims len bytes from the tail of an xdr buf by walking the tail, pages, and head iovecs. Each per-section step uses min t() so it never removes more bytes than that section holds, but the final accounting at the fix len label subtracts the total bytes actually consumed from buf->len without any clamp:

fix len: buf->len -= (len - trim);

When the caller has set buf->len to a value smaller than the sum of the iov lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT MAX. gss krb5 unwrap v2() reaches xdr buf trim() in exactly that state:

buf->head[0].iov len -= GSS KRB5 TOK HDR LEN + headskip; buf->len = len - (GSS KRB5 TOK HDR LEN + headskip); xdr buf trim(buf, ec + GSS KRB5 TOK HDR LEN + tailskip);

buf->len is a small wire-derived value while the iov lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder.

Fix by clamping the decrement so buf->len bottoms out at zero:

buf->len -= min t(unsigned int, buf->len, len - trim);

On the normal path where the iov lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.