PT-2026-90253 · Linux · Linux
CVE-2026-89537
·
Published
2026-09-11
·
Updated
2026-09-11
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Reject short RFC 4121 MIC tokens in gss krb5 verify mic v2
gss krb5 verify mic v2() reads the token ID at ptr[0..1], the flags
byte at ptr[2], and padding at ptr[3..7], then passes
ptr + GSS KRB5 TOK HDR LEN and cksum len to gss krb5 mic build sg().
None of these accesses check read token->len first.
The minimum safe token size is GSS KRB5 TOK HDR LEN (16) plus
ctx->krb5e->cksum len (12-24, depending on the enctype). All callers
accept shorter tokens from the wire:
-
gss unwrap resp integ() enforces only an upper bound (offset + len <= rcv buf->len) before allocating mic.data = kmalloc(len) and passing it to gss verify mic(). A malicious NFS server can therefore supply a short checksum opaque, producing a small slab allocation that the Kerberos MIC verifier reads past.
-
gss validate() enforces only len <= RPC MAX AUTH SIZE (400) before passing the wire-supplied length to gss validate seqno mic(), which constructs a mic xdr netobj and calls gss verify mic().
-
svcauth gss verify header() enforces only checksum.len >= XDR UNIT (4 bytes) before dispatching to gss verify mic().
-
svcauth gss unwrap integ() checks only that the checksum fits in gsd->gsd scratch.
Add a length guard at the top of gss krb5 verify mic v2(), before any
ptr[] access or scatterlist construction. Well-formed MIC tokens from
gss krb5 get mic v2() already have exactly GSS KRB5 TOK HDR LEN +
cksum len bytes, so valid traffic is unaffected.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux