CVE-2026-45870

What it actually does

This is a local, low-complexity denial-of-service vulnerability in the Linux kernel SUNRPC auth_gss XDR decoding paths. Error handling in gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() can leak kernel memory when decoding fails after earlier buffers have already been allocated with kmemdup(). Repeatedly triggering these malformed GSS/RPCSEC_GSS decode error paths can consume unreclaimable kernel memory, potentially causing memory pressure, service instability, or system availability impact. The flaw does not provide direct confidentiality or integrity impact and does not imply code execution by itself.

Why it matters to the business

Systems that use Linux kernel SUNRPC/NFS functionality with GSS/Kerberos-style authentication may be susceptible to local or locally reachable users causing resource exhaustion. In practical terms, exploitation could degrade or interrupt file-sharing, storage, or dependent application workloads on affected Linux hosts. The CVSS availability impact is high, but public exploitation is not currently indicated, EPSS is very low, and the vulnerability is not listed in CISA KEV, so remediation should be prioritized based on exposure of NFS/SUNRPC services and the presence of untrusted local users or multi-tenant workloads.

How an attack unfolds

An attacker first needs the ability to interact with the affected SUNRPC auth_gss handling path, consistent with the local/low-privilege CVSS characterization. They craft inputs that cause XDR decoding of GSS context, status, or name structures to partially succeed so that kernel buffers are allocated, then fail at a later decode step. Because the vulnerable error paths return without freeing earlier allocations, each failed attempt leaks kernel memory. By repeating the operation many times, the attacker can increase unreclaimable kernel memory usage until the host experiences memory pressure, degraded service behavior, or denial of service. There is no evidence from the provided data of public exploit maturity, known ransomware use, or named threat actor exploitation.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the SUNRPC auth_gss memory-leak fix for gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name(). No universal upstream fixed package version was provided, so use the fixed kernel advisory and package version from the relevant Linux distribution or appliance vendor. After installing the corrected kernel package, reboot into the fixed kernel; live patching should only be considered sufficient if the vendor explicitly states that this specific SUNRPC auth_gss fix is included and active. Where immediate patching is not possible, reduce exposure by limiting NFS/SUNRPC services to trusted hosts, disabling unused NFS/RPCSEC_GSS functionality, restricting local shell access to trusted users, and monitoring kernel memory pressure and RPC/GSS decode errors.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor release containing the fix. Validate with commands such as uname -r and the distribution package manager or vendor advisory mapping. Check whether NFS/SUNRPC and Kerberos-authenticated RPC paths are in use by reviewing active RPC services and NFS configuration. Confirm that mitigation controls restrict access to RPC/NFS services where patching is delayed. After remediation, monitor kernel logs and memory metrics under normal RPC/NFS workloads to ensure there are no recurring SUNRPC/auth_gss decode failures accompanied by unreclaimed memory growth.

Typical attack path

1. Obtain low-privileged local access or another permitted path to exercise SUNRPC auth_gss/GSS upcall handling on an affected Linux system.
2. Identify that the host uses vulnerable Linux kernel SUNRPC auth_gss code, commonly relevant to NFS/RPCSEC_GSS or Kerberos-authenticated RPC workflows.
3. Submit malformed or deliberately truncated XDR-encoded GSS data that causes one decode stage to allocate memory and a later stage to fail.
4. Repeat the failing decode operation to leak additional kernel memory.
5. Continue until the system experiences memory pressure, degraded NFS/SUNRPC behavior, service instability, or broader availability loss.

How to detect it

To assess possible prior exploitation, review kernel logs, system journal, audit logs, and NFS/SUNRPC service logs for repeated GSS, RPCSEC_GSS, XDR decode, or auth_gss failures followed by rising kernel memory use, out-of-memory events, hung tasks, or NFS service instability. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, auditd records for local users repeatedly invoking RPC/NFS-related utilities, and service logs for rpc.gssd, rpc.svcgssd, rpcbind, and nfs-server. Because the vulnerability is a memory leak rather than a code-execution flaw, there may be no durable file artifact; evidence is more likely to appear as repeated error patterns, resource exhaustion telemetry, OOM killer activity, service restarts, or unexplained degradation correlated with RPC/GSS authentication attempts. Baseline memory metrics and look for unreclaimed kernel memory growth during periods of repeated SUNRPC/GSS errors.

• SUNRPC
• auth_gss
• rpcsec_gss
• RPCSEC_GSS
• gssx_dec_ctx
• gssx_dec_status
• gssx_dec_name
• XDR decode
• xdr_decode
• rpc.gssd
• rpc.svcgssd
• rpcbind
• nfs-server
• nfsd
• Out of memory
• oom-killer
• Memory allocation failure
• hung task
• kernel: SUNRPC
• kernel: auth_gss

What your security team should do

• Prioritize patching affected Linux systems that provide NFS/SUNRPC services, especially where RPCSEC_GSS/Kerberos authentication is enabled or untrusted users have local access.
• Use vendor advisories to identify the exact fixed kernel package for each Linux distribution, then reboot systems into the fixed kernel.
• Inventory hosts running NFS, rpc.gssd, rpc.svcgssd, rpcbind, or Kerberos-backed RPC workflows to scope exposure.
• Apply network controls so SUNRPC/NFS ports are reachable only from trusted clients and administrative networks.
• Where patching is delayed, consider disabling unused NFS/SUNRPC/GSS functionality and reducing local access to trusted users only.
• Monitor for abnormal kernel memory growth, OOM events, repeated SUNRPC/auth_gss errors, and instability in NFS or storage workloads.
• Treat exploitation likelihood as currently low because EPSS is very low, there is no known KEV listing, and no public exploit maturity is reported, but do not defer indefinitely on shared or high-availability systems.