CVE-2026-89537: SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2

Published Sep 11, 2026
·
Updated

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

SUNRPC: Reject short RFC 4121 MIC tokens in gsskrb5verifymicv2

gsskrb5verifymicv2() reads the token ID at ptr[0..1], the flags byte at ptr[2], and padding at ptr[3..7], then passes ptr + GSSKRB5TOKHDRLEN and cksumlen to gsskrb5micbuildsg(). None of these accesses check readtoken->len first.

The minimum safe token size is GSSKRB5TOKHDRLEN (16) plus ctx->krb5e->cksumlen (12-24, depending on the enctype). All callers accept shorter tokens from the wire:

- gssunwraprespinteg() enforces only an upper bound (offset + len <= rcvbuf->len) before allocating mic.data = kmalloc(len) and passing it to gssverifymic(). A malicious NFS server can therefore supply a short checksum opaque, producing a small slab allocation that the Kerberos MIC verifier reads past.

- gssvalidate() enforces only len <= RPCMAXAUTHSIZE (400) before passing the wire-supplied length to gssvalidateseqnomic(), which constructs a mic xdrnetobj and calls gssverifymic().

- svcauthgssverifyheader() enforces only checksum.len >= XDRUNIT (4 bytes) before dispatching to gssverifymic().

- svcauthgssunwrapinteg() checks only that the checksum fits in gsd->gsdscratch.

Add a length guard at the top of gsskrb5verifymicv2(), before any ptr[] access or scatterlist construction. Well-formed MIC tokens from gsskrb5getmicv2() already have exactly GSSKRB5TOKHDRLEN + cksumlen bytes, so valid traffic is unaffected.

Affected Software

1 affected component
Linux Kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    In gss_krb5_verify_mic_v2(), add a length check at the top before any ptr[ ] accesses or scatterlist/xdr handling. Reject short RFC 4121 MIC tokens that are less than GSS_KRB5_TOK_HDR_LEN (16) + (minimum safe additional fields implied by MIC processing), so well-formed tokens are unaffected.

    Linux kernel SUNRPC (gss_krb5_verify_mic_v2 / GSS-KRB5 MIC token verification) Add length guard in gss_krb5_verify_mic_v2() = Reject tokens shorter than GSS_KRB5_TOK_HDR_LEN (16)
  2. Compensating control

    Apply a kernel/patch update for the SUNRPC issue: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2 to prevent out-of-bounds reads caused by wire-supplied short tokens.

Event History

Sep 11, 2026
CVE Published
via MITRE·07:44 PM
Data Sourced
via MITRE·07:44 PM
Description

Frequently Asked Questions

1

Who can trigger the vulnerable parsing paths?

A malicious NFS server can send a short checksum opaque through gss_unwrap_resp_integ(). Other listed paths accept wire-supplied MIC lengths in client and server-side SUNRPC GSS handling, including gss_validate(), svcauth_gss_verify_header(), and svcauth_gss_unwrap_integ().

2

What token lengths are unsafe?

A MIC token must be at least the 16-byte GSS_KRB5 token header plus the checksum length for the active Kerberos enctype. The checksum length is stated as 12 to 24 bytes depending on enctype, so shorter wire-supplied tokens can cause reads beyond the allocated buffer.

3

Do the affected callers reject undersized MIC tokens by default?

No. The described callers enforce upper bounds or only a 4-byte minimum in one server-side header path, but do not ensure the token is large enough for the header and enctype-specific checksum before verification.

4

How can an administrator determine whether a received token is malformed?

Compare the received MIC token length with 16 bytes plus the checksum length required by the Kerberos enctype in use. Tokens below that threshold are malformed for this verification path.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203