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.