Cloudanix VulnDB

CVE-2026-89714

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Repeated failed attempts to connect to a network file server can silently drain a computer's kernel memory until the system becomes unstable.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Trivial
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Memory leak of 4 KiB delegation_hash_table allocations in nfs4_server_common_setup() when intermediate failures prevent assignment of server->destroy, bypassing nfs4_destroy_server() in nfs_free_server().

Why it matters to the business

Persistent failed NFSv4 mount attempts from automated clients or scripts cause unbounded kernel slab memory growth, risking node instability, OOM kills, or degraded performance in container and storage orchestration environments.

How an attack unfolds

An attacker or misconfigured workload repeatedly invokes mount.nfs4 against an NFSv3-only export or missing path; each failure allocates the hash table without a destroy callback, leaking memory. Sustained retries (as seen with Longhorn backup pollers) accumulate gigabytes of unreclaimable kmalloc-4k slab.

How to fix it

Apply the upstream fix that frees the hash table on all error paths before destroy assignment; upgrade to a kernel containing the patch once released. Monitor and throttle NFS mount retry loops in client automation.

How to confirm the fix worked

Verify kernel source contains the error-path free of delegation_hash_table; confirm /proc/meminfo SUnreclaim growth halts under repeated failed mount attempts and that kmem:kmalloc tracepoint no longer shows nfs4_delegation_hash_alloc on failures.

Typical attack path

  1. Initiate NFSv4 mount to incompatible server or path
  2. nfs4_server_common_setup() allocates delegation_hash_table
  3. Intermediate check (is_ds_only_client, nfs4_init_session, nfs4_get_rootfh, or nfs_probe_server) fails
  4. server->destroy remains NULL so nfs_free_server() skips freeing
  5. Repeat mount attempts to exhaust kernel memory

How to detect it

Inspect kmem:kmalloc tracepoints for call_site=nfs4_delegation_hash_alloc; watch /proc/meminfo SUnreclaim growth correlated with NFS mount failures; review audit or system logs for repeated mount.nfs4 invocations against non-v4 exports.

  • call_site=nfs4_delegation_hash_alloc
  • kmalloc-rnd-13-4k
  • nfs4_server_common_setup

What your security team should do

  • Identify and correct NFS mount automation that retries against incompatible servers
  • Apply kernel update containing the delegation hash table error-path fix
  • Add memory-leak monitoring for kmalloc-rnd-13-4k slab via kmem tracepoints
  • Rate-limit or circuit-break mount.nfs4 retries in orchestration tooling

The record

In the Linux kernel, the following vulnerability has been resolved: NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails nfs4_server_common_setup() allocates server->delegation_hash_table first, but server->destroy - the only path that frees the table via nfs4_destroy_server() - is not assigned until the very end of the function. If any intermediate step fails (the is_ds_only_client() check, nfs4_init_session(), nfs4_get_rootfh(), or nfs_probe_server()), the function returns with server->destroy still NULL, so the caller's nfs_free_server() skips the destroy callback and the hash table is leaked (4 KiB per attempt with the default delegation watermark). This is trivially reachable from userspace: every failed NFSv4 mount leaks one allocation. A client that persistently retries a mount that cannot succeed leaks kernel memory without bound. Observed in production where a Longhorn backup poller retried mount.nfs4 against an NFSv3-only server roughly 10 times per second, leaking ~3.4 GiB of unreclaimable slab (kmalloc-rnd-13-4k) per day; the node accumulated 12 GiB of leaked slab before the source was identified via the kmem:kmalloc tracepoint (call_site=nfs4_delegation_hash_alloc). Reproducer: # server exports NFSv3 only (or export path absent for v4) while :; do mount -t nfs4 <server>:/missing /mnt; done # watch SUnreclaim in /proc/meminfo grow 4 KiB per iteration Free the table on the error paths between the allocation and the assignment of server->destroy.

Affected packages

Ecosystem Package Introduced Fixed