CVE-2026-89714: Linux Kernel NFS Privilege Escalation Flaw

CVE-2026-89714 Overview

CVE-2026-89714 is a memory leak vulnerability in the Linux kernel's NFSv4 client implementation. The flaw resides in nfs4_server_common_setup(), which allocates server->delegation_hash_table before assigning the server->destroy callback. When any intermediate initialization step fails, the caller's nfs_free_server() skips the destroy callback and the hash table remains allocated. Each failed NFSv4 mount leaks 4 KiB of unreclaimable slab memory. The condition is reachable from unprivileged userspace through repeated mount attempts against an incompatible server.

Critical Impact
An unprivileged local user or misconfigured client retrying failed NFSv4 mounts can exhaust kernel memory without bound, leading to denial of service on the affected node.

Affected Products

Linux kernel (NFSv4 client subsystem)
Distributions shipping vulnerable kernel versions prior to the referenced stable commits
Systems mounting NFSv4 shares where mount failures may recur

Discovery Timeline

2026-09-11 - CVE CVE-2026-89714 published to NVD
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-89714

Vulnerability Analysis

The defect is a classic error-path resource leak [CWE-401] in the Linux NFSv4 client. nfs4_server_common_setup() performs several ordered initialization steps: allocating the delegation hash table, running is_ds_only_client() checks, calling nfs4_init_session(), nfs4_get_rootfh(), and nfs_probe_server(). The server->destroy function pointer, which alone triggers nfs4_destroy_server() and frees the hash table, is assigned only after all of these succeed.

If any intermediate step returns an error, control returns to the caller with server->destroy still NULL. The caller invokes nfs_free_server(), which sees no destroy callback and releases the server structure without freeing the previously allocated delegation_hash_table. Each failed mount attempt leaks 4 KiB of kmalloc-rnd-13-4k slab memory.

Root Cause

The root cause is an incorrect ordering of resource ownership. The allocation is performed early, but the cleanup handler that owns freeing that allocation is registered late. Any failure in the window between the allocation and the assignment produces an orphaned allocation that no cleanup path can reclaim.

Attack Vector

The leak is trivially triggered from userspace. A reproducer documented in the commit message issues mount -t nfs4 <server>:/missing /mnt in a loop against a server that exports only NFSv3 or lacks the requested export path. SUnreclaim in /proc/meminfo grows by 4 KiB per iteration. A production report cited a Longhorn backup poller retrying mount.nfs4 roughly 10 times per second and leaking approximately 3.4 GiB of unreclaimable slab per day, accumulating 12 GiB before the source was identified through the kmem:kmalloc tracepoint with call_site=nfs4_delegation_hash_alloc.

The vulnerability requires only the ability to invoke mount(2) with an NFSv4 target, or the presence of an automounter or orchestration component that retries failed mounts.

Detection Methods for CVE-2026-89714

Indicators of Compromise

Steady growth of SUnreclaim in /proc/meminfo on hosts that perform NFSv4 mounts.
Increasing allocations attributed to kmalloc-rnd-13-4k visible in /proc/slabinfo.
kmem:kmalloc tracepoint events with call_site=nfs4_delegation_hash_alloc that are not matched by corresponding frees.
Repeated failed mount.nfs4 invocations logged in system journals against unreachable or incompatible NFS servers.

Detection Strategies

Correlate mount failure events from journalctl or dmesg with slab growth deltas over time.
Instrument perf or bpftrace on the nfs4_delegation_hash_alloc and matching free paths to quantify unbalanced allocations.
Baseline expected SUnreclaim growth per host role and alert on sustained upward drift.

Monitoring Recommendations

Track kernel slab metrics through node exporters and alert on unbounded SUnreclaim trends.
Monitor mount unit failures in systemd and orchestration platforms such as Kubernetes or Longhorn that manage NFS-backed volumes.
Log kernel version inventory across the fleet to prioritize patch rollout on hosts that mount NFSv4.

How to Mitigate CVE-2026-89714

Immediate Actions Required

Apply the upstream Linux kernel fix that frees the delegation hash table on error paths between allocation and the assignment of server->destroy.
Identify and stop clients or controllers that continuously retry failing NFSv4 mounts.
Reboot hosts that have already accumulated significant leaked slab to reclaim unreclaimable memory.

Patch Information

The fix is committed to the mainline and stable Linux kernel trees. See the upstream commits: Linux kernel commit 0fd2b968, Linux kernel commit 2092f5b3, and Linux kernel commit f3adf164. Rebuild or update to a kernel version incorporating these commits and reboot affected hosts.

Workarounds

Configure clients to mount using a protocol the server actually supports, avoiding NFSv4 targets against NFSv3-only exports.
Add backoff or circuit-breaker logic in automounters, backup pollers, and orchestrators to prevent tight retry loops on failed mounts.
Restrict which users and services can invoke mount(2) on multi-tenant hosts to reduce exposure until the patch is deployed.

bash

# Confirm kernel version and inspect NFS delegation hash allocations
uname -r
grep -E 'SUnreclaim|Slab' /proc/meminfo
awk '/kmalloc-rnd-13-4k/ {print}' /proc/slabinfo

# Trace unbalanced allocations attributed to the NFSv4 delegation hash
perf record -e kmem:kmalloc --filter 'call_site == nfs4_delegation_hash_alloc' -a -- sleep 60