CVE-2026-89539

What it actually does

The Linux kernel SUNRPC GSSX option-array decoder walks a wire-supplied option list and, for every name matching CREDS_VALUE, calls gssx_dec_linux_creds() on the same svc_cred. That helper unconditionally installs a new groups_alloc() result into cr_group_info without releasing any pointer already stored there. A reply with two or more CREDS_VALUE entries therefore overwrites cr_group_info on the later iteration and orphans the earlier kvmalloc-backed group_info. The free_creds path only drops the last installed group_info via free_svc_cred(), so the first allocation remains referenced and is leaked. Repeated decoding of such replies produces a kernel memory leak that can exhaust memory and deny service on RPC/GSS paths. No in-tree caller of gssp_accept_sec_context_upcall() expects more than one CREDS_VALUE per reply. The intended fix tracks whether a CREDS_VALUE option was already decoded and returns -EINVAL on any subsequent match so only a single group_info is installed and later released.

Why it matters to the business

Systems that use kernel SUNRPC with GSS (commonly NFS file sharing with Kerberos/gss-proxy) can suffer progressive kernel memory growth, latency, and eventual out-of-memory failures that disrupt file services and may force a reboot. Impact is availability, not confidentiality or integrity of data. The issue is not in CISA KEV, is not associated with ransomware campaigns, and has no reported exploit maturity, so mass in-the-wild abuse is not indicated. About 34 days have passed since publication, which is enough time for distribution kernels to carry the fix; unpatched long-lived NFS/RPC gateways remain the main residual operational risk.

How an attack unfolds

An attacker who can cause the kernel to decode a GSSX accept-context reply whose option array contains more than one CREDS_VALUE entry triggers the leak: the first option allocates group_info, the second overwrites the pointer, and the first allocation is never freed. That influence is most plausible through a compromised, buggy, or attacker-controlled userspace GSS helper on the upcall path, or any other input that reaches gssx_dec_option_array() with duplicate credential options. Each successful decode leaks kernel memory; sustained repetition can exhaust kmalloc/kvmalloc capacity, induce OOM behavior in nfsd/RPC and unrelated tasks, and take the host down. There are no named threat actors, KEV listings, or public exploit reports tied to this flaw. Exploitation yields denial of service via resource exhaustion, not code execution.

How to fix it

Install a vendor or upstream Linux kernel that includes the SUNRPC change to reject duplicate CREDS_VALUE options in gssx_dec_option_array() (subsequent matches return -EINVAL so only one group_info is installed and freed). Reboot onto the patched kernel. Exact package versions were not supplied with this record, so map CVE-2026-89539 to your distribution’s kernel advisory and upgrade to that fixed release. If a patch is not yet available, reduce exposure of NFS/RPCSEC_GSS services, restrict which processes may perform GSS upcalls, and plan a maintenance reboot as soon as a fixed kernel ships. There is no complete userspace-only workaround for the kernel leak.

How to confirm the fix worked

Confirm the running kernel changelog or distro CVE tracker lists CVE-2026-89539 or the SUNRPC ‘reject duplicate CREDS_VALUE options’ commit, then verify the host has rebooted into that kernel. On a test system with kmemleak enabled, exercise GSS accept-context/upcall traffic and confirm no growing unreferenced group_info objects from gssx_dec_linux_creds/groups_alloc. Review slab/kvmalloc trends for rpc/nfsd-related caches before and after the upgrade; growth that stops after the patch indicates the leak is closed. Do not attempt to send crafted duplicate-option replies on production hosts to prove the bug.

Typical attack path

1. Identify a Linux host using SUNRPC/RPCSEC_GSS (for example NFS with a GSS upcall helper).
2. Cause the kernel GSSX decoder to process an accept-context reply whose option array contains duplicate CREDS_VALUE entries.
3. On each such reply the kernel overwrites cr_group_info and leaks the prior groups_alloc() allocation.
4. Repeat until kernel memory is exhausted and RPC or other workloads fail or the host becomes unresponsive.

How to detect it

This flaw leaves no reliable network signature or dropped malware; detection of prior abuse is forensic and resource-based. On hosts that ran unpatched kernels with NFS/RPCSEC_GSS, review kmemleak (if enabled) and kernel logs for unreferenced objects whose backtrace includes gssx_dec_linux_creds, gssx_dec_option_array, groups_alloc, or gssp_accept_sec_context_upcall. Correlate unexplained kvmalloc/kmalloc growth and OOM killer events involving nfsd, sunrpc, or gss-proxy/rpc.gssd with periods of GSS accept-context activity. Sudden host-wide memory pressure without a matching userspace allocator is more informative than packet captures. Absence of those artifacts does not prove the leak never fired; presence of repeated leaks on that call path on an unpatched kernel is the strongest post-facto indicator.

• gssx_dec_linux_creds
• gssx_dec_option_array
• gssp_accept_sec_context_upcall
• groups_alloc

What your security team should do

• Patch and reboot Linux NFS/RPC/GSS servers to a kernel that rejects duplicate CREDS_VALUE options; treat long-lived file-sharing gateways first.
• Inventory hosts with nfsd, rpc.gssd/gss-proxy, or other kernel GSS upcall users and track kernel version versus vendor fixed releases.
• Until patched, constrain who can talk to GSS upcall helpers and avoid exposing RPCSEC_GSS to untrusted networks.
• Watch kernel memory, OOM events, and kmemleak reports on RPC/NFS nodes for leak evidence; this is not a KEV/ransomware item so prioritize as a DoS/availability fix rather than emergency CISA-due work.
• After patching, confirm the new kernel is actually running and that memory growth on those hosts has stabilized.