CVE-2026-89537

What it actually does

The Linux kernel SUNRPC GSS Kerberos v2 MIC verifier (gss_krb5_verify_mic_v2) performs out-of-bounds reads on RFC 4121 MIC tokens that are shorter than the required 16-byte token header plus the enctype checksum (typically 12–24 bytes). Callers accept undersized tokens from the wire and allocate correspondingly small slab buffers; the verifier then indexes past those buffers for the token ID, flags, padding, and checksum. This kernel heap out-of-bounds read can disclose adjacent slab contents (high confidentiality impact) and trigger oopses or panics (high availability impact), with no integrity impact in the scored model. Both NFS/RPC clients processing malicious server MIC/checksum opaques and servers processing malformed GSS tokens are in scope.

Why it matters to the business

Systems that mount NFS or otherwise use SUNRPC with GSS-Kerberos can be crashed remotely—taking down the whole host, not just a userspace daemon—or can leak kernel memory to an untrusted peer. File-sharing, HPC, and identity-backed RPC workloads are the primary operational risk. The issue has been public for about 34 days, is not in CISA KEV, is not associated with ransomware, and has no reported exploit maturity, but the 9.1 network-unauthenticated kernel rating still justifies fast patching of NFS clients and GSS-enabled RPC servers.

How an attack unfolds

An unauthenticated remote party who can deliver SUNRPC/GSS traffic—most directly a malicious or compromised NFS server answering a client, or a client sending GSS tokens to an RPC service—supplies a MIC/checksum token shorter than the header-plus-checksum minimum. Existing callers only apply loose upper bounds (or a 4-byte minimum), so the kernel allocates a small object and enters gss_krb5_verify_mic_v2, which reads past that object before any length guard. The out-of-bounds read can panic the host or expose neighboring kernel heap. Well-formed tokens already emitted at exactly header-plus-checksum length are unaffected. No named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Apply a Linux kernel update that includes the SUNRPC fix adding a length guard at the top of gss_krb5_verify_mic_v2 before any ptr[] access or scatterlist construction (reject tokens shorter than GSS_KRB5_TOK_HDR_LEN plus cksum_len). Use your distribution or stable/LTS kernel packages; no per-package fixed versions were supplied with this record. There is no complete userspace workaround. Until patched: do not mount NFS from untrusted servers; restrict NFS/SUNRPC (typically TCP/UDP 2049 and related rpcbind ports) to trusted networks; and prefer isolating GSS-Kerberos RPC from untrusted clients. Disabling Kerberos integrity on NFS is not a recommended substitute for the kernel patch.

How to confirm the fix worked

Confirm the running kernel changelog or distro advisory lists CVE-2026-89537 or the SUNRPC change that rejects short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2. On source kernels, verify a minimum-length check exists before header/checksum access in that function. After upgrade, uname -r should match a patched package; reboot so the new kernel is actually running. Do not validate by sending truncated MIC tokens on production hosts. Inventory NFS mounts and GSS-enabled RPC services to find remaining unpatched nodes.

Typical attack path

1. Gain the ability to send SUNRPC/GSS-Kerberos MIC or integrity checksum material (malicious NFS server, untrusted RPC client, or on-path injection where GSS is used).
2. Send a truncated RFC 4121 MIC/checksum opaque that still passes caller-side checks (upper bound or 4-byte minimum, within RPC auth size / scratch-buffer limits).
3. Kernel allocates a small slab buffer and invokes gss_krb5_verify_mic_v2 without a minimum-length check.
4. Verifier reads token header and checksum fields past the allocated object.
5. Host experiences a kernel oops/panic and/or an out-of-bounds read of adjacent heap, impacting availability and confidentiality of the NFS/RPC endpoint.

How to detect it

This is an in-kernel out-of-bounds read with no public exploit, so evidence of prior abuse is mostly crash forensics rather than malware artifacts. Review dmesg, journalctl -k, netconsole, kdump/vmcore, and crash/oops archives around NFS or RPC activity for panics or KASAN reports whose call traces include gss_krb5_verify_mic_v2, gss_krb5_mic_build_sg, gss_verify_mic, gss_unwrap_resp_integ, gss_validate, gss_validate_seqno_mic, svcauth_gss_verify_header, or svcauth_gss_unwrap_integ. Correlate oops timestamps with NFS mount/traffic to untrusted servers or with inbound GSS/RPC from unexpected clients. Look for sudden NFS-client or rpc.gssd-related host reboots without a matching admin change. Packet captures of truncated GSS MIC tokens are supporting context only; they are not a reliable standalone IOC. Absent an oops in this path, exploitation is unlikely to be distinguishable from benign GSS traffic.

• gss_krb5_verify_mic_v2
• gss_krb5_mic_build_sg
• gss_unwrap_resp_integ
• gss_validate_seqno_mic
• svcauth_gss_verify_header
• svcauth_gss_unwrap_integ
• BUG: KASAN: slab-out-of-bounds
• Unable to handle kernel paging request

What your security team should do

• Patch and reboot Linux NFS clients and GSS/SUNRPC servers first; treat this as a high-severity kernel memory-safety fix despite no KEV listing or known exploits.
• Inventory hosts that mount NFS (especially from third-party or less-trusted filers) and hosts that offer GSS-Kerberos RPC, and track kernel package versions until all are patched.
• Until patched, block or tightly ACL NFS/SUNRPC from untrusted networks and avoid new mounts of untrusted NFS exports.
• Watch kernel logs and crash dumps for oopses in the GSS/SUNRPC MIC path; escalate unexpected NFS-client panics after talking to a remote filer.
• Do not delay for exploit proof: CVSS 9.1, kernel blast radius, and 34 days of public disclosure already justify scheduled emergency patching.