CVE-2026-89541

What it actually does

A 32-bit integer wrap in the Linux kernel SUNRPC client function gss_unwrap_resp_priv() lets a crafted RPCSEC_GSS opaque length bypass the receive-buffer bounds check. The same check also lacks a minimum-length floor, so undersized tokens are forwarded into gss_krb5_unwrap_v2() and the following rotate_left() loop. The result is kernel-space out-of-bounds reads on NFS clients using Kerberos privacy (krb5p), which can disclose kernel memory, panic the host, and is scored as complete confidentiality, integrity, and availability impact.

Why it matters to the business

Linux NFS clients that use RPCSEC_GSS with krb5p can be crashed or have kernel memory exposed by a hostile or compromised NFS server, taking down workloads that depend on those mounts with no user action required. The issue is about a month old, is not in CISA KEV, and has no known public exploit, but the critical severity still warrants accelerated patching of NFS client fleets—especially where storage is multi-tenant, partner-hosted, or otherwise not fully trusted.

How an attack unfolds

An attacker who operates or impersonates a krb5p NFS server waits for a Linux NFS client to send an RPCSEC_GSS privacy-protected request. The attacker returns a crafted GSS-wrapped reply whose opaque token length is either near the 32-bit maximum, so the offset-plus-length sum wraps to a small in-bounds-looking value, or below the Kerberos outer-token header size. The defective check accepts the reply, gss_unwrap runs with an inverted or truncated range, and the client kernel reads past the token in gss_krb5_unwrap_v2 and rotate_left, causing memory disclosure or a kernel oops without privileges or interaction on the victim.

How to fix it

Install Linux kernel updates from your distribution or upstream that harden gss_unwrap_resp_priv with separate, wrap-safe guards: offset versus receive-buffer length, opaque_len versus remaining length, and opaque_len at least GSS_KRB5_TOK_HDR_LEN. Reboot onto the patched kernel and retire the old image as the default. Until patched, mount NFS only from trusted servers, avoid krb5p to untrusted networks, and if operations allow, use integrity-only or less-exposed security flavors instead of privacy wrapping. Track vendor kernel advisories for the exact package that ships your kernel; this record does not list per-distro fixed versions.

How to confirm the fix worked

Inventory hosts with NFS client mounts using sec=krb5p (fstab, autofs, /proc/mounts). Confirm uname -r matches a distro advisory that includes the SUNRPC gss_unwrap_resp_priv length-check fix, or that the kernel changelog contains that hardening. Verify sunrpc, auth_rpcgss, and rpcsec_gss_krb5 modules come from the patched build, reboot, and ensure an unpatched kernel is not still the default boot entry.

Typical attack path

1. Attacker controls or impersonates an NFS server that offers Kerberos privacy (RPCSEC_GSS / krb5p).
2. A Linux NFS client mounts or continues using that export.
3. The client issues an RPC that will be unwrapped via gss_unwrap_resp_priv.
4. The attacker returns an RPCSEC_GSS private reply with an opaque length that wraps the u32 bounds check or is shorter than the Kerberos token header.
5. The kernel accepts the reply and performs out-of-bounds reads in the GSS Kerberos unwrap path.
6. The client leaks kernel memory or panics, disrupting NFS-dependent services.

How to detect it

There is no public exploit and no named campaign, so look for post-crash artifacts rather than a known payload. Review dmesg, journalctl --dmesg, persistent kernel logs, kdump/vmcore, and oops/panic collectors for faults whose stack includes gss_krb5_unwrap_v2, gss_unwrap, auth_rpcgss, rpcsec_gss_krb5, or sunrpc while the host had NFS client mounts with Kerberos privacy. Correlate client instability with RPCSEC_GSS traffic to unexpected or untrusted NFS servers. Absent an oops, this issue leaves little reliable network residue because the malformed reply is processed in-kernel on the client.

• gss_krb5_unwrap_v2
• gss_unwrap_resp_priv
• rpcsec_gss_krb5
• auth_rpcgss
• Call Trace:.*sunrpc
• Oops:.*rpcsec_gss
• sec=krb5p

What your security team should do

• Treat Linux NFS clients using RPCSEC_GSS krb5p as a critical kernel patching cohort despite the lack of KEV listing or public exploit.
• Inventory NFS client mounts and rpcsec_gss usage to find exposed systems before and after patching.
• Until kernels are updated, restrict krb5p NFS to trusted servers and networks only.
• Watch kernel logs and crash dumps for oopses in the SUNRPC GSS Kerberos unwrap path coincident with NFS client activity.
• After rollout, verify running kernels include the fix and that older kernels are not bootable by default.