CVE-2026-89542

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

SUNRPC: harden gss_krb5_unwrap_v2 against short tokens

gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and

ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN

(16) bytes long, and its rotate_left() helper passes buf->len - base

to xdr_buf_subsegment() without verifying that base <= buf->len. When

a caller hands in a sub-16-byte token, or a token whose declared len

leaves base past the end of the buffer, three distinct failures follow:

gss_krb5_unwrap_v2(offset, len, buf)

ptr = buf->head[0].iov_base + offset

ec = *(ptr + 4) /* OOB read on short head */

rrc = *(ptr + 6) /* OOB read on short head */

rotate_left(offset + 16, buf, rrc)

xdr_buf_subsegment(buf, &subbuf,

base, buf->len - base) /* u32 wrap when base > len */

_rotate_left(&subbuf, shift)

shift %= buf->len /* divide-by-zero when base == len */

After decryption, the cleanup arithmetic has the same shape:

movelen = min_t(unsigned int, buf->head[0].iov_len, len);

movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip;

BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen >

buf->head[0].iov_len);

The BUG_ON re-adds the value just subtracted, so it reduces to

min(A, B) > A and is permanently false; it cannot catch the unsigned

underflow of movelen, which then drives a ~UINT_MAX-byte memmove().

Add four defense-in-depth guards inside the unwrap core so it is safe

regardless of what its callers validate:

- reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before

touching ptr+4/ptr+6;

- bail from rotate_left() when buf->len <= base, covering both the

underflow and zero-length cases;

- return early from _rotate_left() when buf->len is zero, so the

shift %= buf->len modulo cannot fault;

- replace the dead BUG_ON with a live check that returns

GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.