CVE-2026-89538

What it actually does

The Linux kernel SUNRPC Kerberos v2 unwrap path (gss_krb5_unwrap_v2) can accept a wrap token whose extra-count (ec) field is larger than the remaining wrapped segment. After a successful decrypt, xdr_buf_trim() is driven with that oversized length, leaving the RPC XDR buffer at zero or otherwise inconsistent iovec/len state and potentially trimming bytes that precede the wrapped blob. Later SUNRPC/NFS processing of that buffer is memory-unsafe and can panic the kernel or corrupt adjacent RPC data.

Why it matters to the business

Hosts that serve or consume NFS and other kernel SUNRPC services with Kerberos (rpcsec_gss / sec=krb5, krb5i, krb5p) can suffer kernel crashes, hung mounts, and shared-storage outages, which cascade into application and cluster downtime. The issue is scored critical (CVSS 9.8) and has been public for more than a month, so unpatched NFS/RPC servers remain a high operational risk even though it is not in CISA KEV, is not tied to ransomware campaigns, and has no reported exploit maturity.

How an attack unfolds

An attacker who already holds a valid GSS/Kerberos context to the target encrypts an RFC 4121 Kerberos v2 wrap token whose extra-count exceeds the plaintext wrapped length. Integrity checks that compare the decrypted header still pass because a legitimate context holder produced the token, but the token is structurally malformed. The kernel unwraps it, applies xdr_buf_trim() using the oversized ec (including a window where the trim cuts into offset bytes ahead of the blob), and leaves the XDR buffer internally inconsistent. Subsequent RPC receive handling can then crash the host or operate on corrupted buffer state. Random unauthenticated mutation of ec is rejected; a valid GSS peer is required.

How to fix it

Install the Linux kernel update from your distribution that rejects Kerberos v2 wrap tokens with an oversized extra-count before xdr_buf_trim(), returning GSS_S_DEFECTIVE_TOKEN and keeping the XDR buffer consistent (trim length must be checked against buf->len minus offset, not the whole buffer). Reboot into the patched kernel so nfsd, sunrpc, and auth_rpcgss/rpcsec_gss_krb5 run the fixed code. If vendor packages are not yet available, carry the corresponding stable-tree SUNRPC fix through your kernel build process. Until patched, restrict which principals can establish GSS contexts, disable krb5/krb5i/krb5p RPC flavors where Kerberos is not required, and keep SUNRPC/NFS off untrusted networks. No userspace setting fully closes this kernel path. Specific fixed package versions were not provided with this record; use your distro advisory for the exact kernel RPM/DEB.

How to confirm the fix worked

Confirm the running kernel changelog or source includes the gss_krb5_unwrap_v2 check that compares extra-count against the remaining wrapped segment (buf->len - offset) before xdr_buf_trim(). Verify uname -r matches a vendor kernel advertised as fixing this SUNRPC GSS issue and that sunrpc/auth_rpcgss modules load from that image. Inventory hosts with nfsd, kernel NFS clients, or sec=krb5/krb5i/krb5p mounts as in-scope. After the patch, oversized-ec wrap tokens should fail closed with GSS_S_DEFECTIVE_TOKEN rather than a zero-length or inconsistent xdr_buf, and there should be no oops in the unwrap/trim path from that input.

Typical attack path

1. Obtain or reuse a valid GSS/Kerberos security context to a Linux NFS or other SUNRPC service using rpcsec_gss.
2. Send a Kerberos v2 wrap token whose extra-count (ec) exceeds the remaining wrapped segment (buf length minus blob offset).
3. Cause gss_krb5_unwrap_v2 to call xdr_buf_trim() on that oversized value after decrypt.
4. Leave the kernel XDR buffer at zero or inconsistent length, possibly truncating bytes before the wrapped blob.
5. Depend on later SUNRPC/NFS use of that buffer to panic the kernel or induce memory corruption.

How to detect it

Successful pre-crash exploitation has no stable network signature because the extra-count field sits inside an encrypted Kerberos wrap token. Hunt kernel logs (dmesg, journalctl -k, kern.log) and kdump/vmcore stacks for oops, panic, or BUG involving gss_krb5_unwrap_v2, xdr_buf_trim, auth_rpcgss, rpcsec_gss_krb5, or net/sunrpc/auth_gss during NFS/RPC activity. Correlate with nfsd or lockd failures, hung Kerberos-secured NFS mounts, and client reconnect storms from a principal that holds a valid ticket. RPCSEC_GSS packet captures are supporting context only. After patching, unwrap failures consistent with GSS_S_DEFECTIVE_TOKEN indicate rejection of malformed tokens, not compromise. No named threat actors or KEV/ransomware use is associated with this issue.

• gss_krb5_unwrap_v2
• xdr_buf_trim
• net/sunrpc/auth_gss/
• rpcsec_gss_krb5
• auth_rpcgss
• GSS_S_DEFECTIVE_TOKEN
• [nfsd]
• rpc.svcgssd
• rpc.gssd

What your security team should do

• Patch and reboot NFS servers and any host using rpcsec_gss/Kerberos for SUNRPC first; this is kernel memory corruption with a critical score.
• Enumerate exposure: nfs-kernel-server/nfsd, rpc.svcgssd/rpc.gssd, and mounts with sec=krb5, krb5i, or krb5p.
• Until patched, limit GSS principals to those services and isolate NFS/RPC from untrusted networks.
• Hunt kernel logs and kdumps for oopses in gss_krb5_unwrap_v2, xdr_buf_trim, auth_rpcgss, or net/sunrpc; this CVE is not in KEV and has no known exploit maturity, but crashes in that path are suspicious.
• Track distribution advisories for the exact kernel package that carries the SUNRPC oversized-ec rejection and verify it is running after reboot.