CVE-2026-45964

What it actually does

This vulnerability is a Linux kernel SUNRPC/RPCSEC_GSS reference-counting bug in the gss_alloc_msg error path. When a GSS authentication message is allocated with a non-NULL service name and kstrdup_const() fails, the code releases some resources but fails to drop a previously acquired gss_auth reference. Repeatedly triggering this path can leak kernel references and associated memory until the affected authentication structure is never freed, potentially causing kernel memory pressure, service instability, or a local denial of service. The flaw does not provide direct confidentiality or integrity impact and is assessed as local, low-complexity exploitation requiring local privileges.

Why it matters to the business

Systems that rely on affected Linux kernels, especially servers using SUNRPC, NFS, or RPCSEC_GSS/Kerberos-secured NFS functionality, may be susceptible to local denial-of-service conditions. A low-privileged local user or compromised local workload could repeatedly trigger kernel memory/resource leakage, degrading performance or causing service disruption. Because the issue is not in CISA KEV, has no known mature public exploit, and has low EPSS, broad internet-driven exploitation is unlikely; however, shared Linux hosts, multi-user systems, CI/build workers, container hosts, and NFS infrastructure should still treat kernel availability defects as operationally important.

How an attack unfolds

An attacker first obtains the ability to run code or issue relevant local operations on a vulnerable Linux system. They then interact with kernel SUNRPC/GSS authentication paths, typically in environments where NFS or RPCSEC_GSS functionality is available, and attempt to force memory-allocation failure during service-name duplication in gss_alloc_msg. When that allocation fails, the vulnerable error path frees some temporary objects but leaves the gss_auth reference count elevated. By repeating the operation, the attacker accumulates leaked references and related kernel memory/resource pressure. Over time this can exhaust available memory or destabilize kernel services, leading to degraded availability, failed NFS/RPC operations, out-of-memory conditions, or system hang/reboot behavior depending on workload and memory pressure.

How to fix it

Apply a Linux kernel update that includes the upstream SUNRPC fix for the gss_auth kref leak in gss_alloc_msg. Because no exact fixed package versions were provided, use the vendor advisory and package metadata for the relevant distribution or kernel branch to identify the corrected kernel build. After installing the fixed kernel, reboot into the updated kernel and confirm the running kernel version, not only the installed package version. Where immediate patching is not possible, reduce exposure by limiting local shell access, constraining untrusted workloads, disabling or restricting unused NFS/SUNRPC/RPCSEC_GSS functionality, enforcing least privilege, and applying cgroup/container memory limits to reduce the blast radius of local resource-exhaustion attempts. These mitigations reduce exploitability but do not correct the kernel reference leak.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the vendor backport or upstream commit that adds the missing kref_put() on the err_put_pipe_version path in auth_gss.c. Validate with package-manager queries and runtime checks such as uname -r, distribution kernel changelogs, and vendor CVE status pages. Confirm that the host has rebooted into the fixed kernel after patch installation. For exposure validation, check whether SUNRPC/NFS/RPCSEC_GSS components are in use or loaded, for example by reviewing loaded kernel modules, NFS mounts/exports, rpc.gssd usage, and Kerberos-secured NFS configuration. In controlled testing, monitor memory stability while exercising legitimate NFS/RPCSEC_GSS workflows; do not rely on exploit reproduction in production because the failure path depends on allocation failure and may destabilize the system.

Typical attack path

1. Gain low-privileged local execution on a Linux system running an affected kernel.
2. Identify that SUNRPC, NFS, or RPCSEC_GSS/Kerberos-related kernel paths are available or loaded.
3. Trigger GSS authentication message allocation paths with a non-NULL service name.
4. Apply memory pressure or otherwise induce kstrdup_const() allocation failure during gss_alloc_msg processing.
5. Repeat the failing operation so the missing kref_put() leaks gss_auth references.
6. Cause progressive kernel memory/resource exhaustion, resulting in degraded service availability or denial of service.

How to detect it

There is no highly specific network indicator for this vulnerability because exploitation is local and abuses an internal kernel error path. Detection should focus on signs of prior or attempted denial-of-service activity: kernel memory pressure without an obvious workload cause, repeated OOM-killer events, hung tasks, NFS/RPCSEC_GSS failures, rpc.gssd instability, and unusual local processes repeatedly invoking NFS/RPC/Kerberos-secured file operations while memory is constrained. Review system journals, kernel logs, audit logs, process accounting, EDR telemetry, NFS client/server logs, and authentication/session logs for local users active immediately before memory exhaustion or NFS/RPC failures. Correlate events such as rapidly increasing memory usage, slab growth, OOM kills, task stalls, and SUNRPC/GSS/NFS error messages. Treat the listed indicators as hunting leads rather than proof of exploitation, because normal memory pressure or NFS outages can produce similar artifacts.

• auth_gss
• gss_alloc_msg
• rpc.gssd
• rpc-svcgssd
• RPCSEC_GSS
• SUNRPC
• nfs
• nfsd
• oom-killer
• Out of memory
• invoked oom-killer
• Memory allocation failure
• page allocation failure
• hung task
• blocked for more than
• kernel: NFS
• kernel: RPC
• kernel: sunrpc

What your security team should do

• Prioritize patching Linux systems that provide or consume NFS, use RPCSEC_GSS/Kerberos-secured NFS, host multiple local users, or run untrusted workloads.
• Track vendor-specific kernel advisories and deploy the first fixed kernel available for each supported distribution or kernel branch.
• Ensure systems are rebooted into the corrected kernel after update; kernel package installation alone is insufficient.
• Restrict local interactive access and untrusted workload execution on vulnerable systems until patching is complete.
• Review whether NFS, SUNRPC, rpc.gssd, or Kerberos-secured NFS functionality is required; disable or restrict unused services.
• Monitor vulnerable systems for unexplained kernel memory growth, OOM-killer activity, hung tasks, NFS/RPC instability, or repeated local activity correlated with memory pressure.
• Use cgroups, container limits, and workload isolation to reduce the impact of local resource-exhaustion attempts on shared hosts.
• Because there is no KEV listing, ransomware association, or known exploit maturity in the provided data, handle as a defense-in-depth kernel availability issue rather than an emergency internet-exposed RCE event.