Linux NFS client: every failed NFSv4 mount leaks 4 KiB of unreclaimable slab

Impact

nfs4_server_common_setup() allocates server->delegation_hash_table before assigning server->destroy, so any intermediate failure (is_ds_only_client(), nfs4_init_session(), nfs4_get_rootfh(), nfs_probe_server()) returns with destroy still NULL and nfs_free_server() never frees the table. Each failed NFSv4 mount leaks 4 KiB of unreclaimable slab, without bound. The record documents this in production: a Longhorn backup poller retrying mount.nfs4 against an NFSv3-only server roughly ten times a second leaked about 3.4 GiB of slab per day and reached 12 GiB before the source was found. On a GPU node this is the expensive kind of failure - unreclaimable kernel memory squeezes the host until workloads are OOM-killed, and the only recovery is a reboot that costs a drain of long-running jobs. Any controller that retries a broken mount in a loop reproduces it with no attacker at all.

Who can reach it

Local, and in practice unauthenticated by accident: any process or controller that can call mount -t nfs4 against a server that cannot satisfy it. A misconfigured storage class or a tenant permitted to mount NFS is enough; no exploit is needed.

What to do

Patch the kernel on client nodes - the fix frees the table on the error paths between allocation and the server->destroy assignment - and reboot each node to clear already-leaked slab. Until then, stop the retry loop: fix or remove the failing mount target, or rate-limit the mounting controller. Watch SUnreclaim in /proc/meminfo and the kmem:kmalloc tracepoint with call_site=nfs4_delegation_hash_alloc to confirm whether a node is affected.

References

Related entries

• Linux NFS localio: reference leak on nfs_uuid_add_file failure pins an nfsd_file and blocks netns teardownCVE-2026-89715 · Linux kernel NFS localio (nfs_open_local_fh error path, nfs_uuid_add_file)Unscored
• KVM arm64 vGICv2: guest write of an out-of-range GICV_DIR INTID triggers a host WARN and panics panic_on_warn hostsCVE-2026-89727 · Linux kernel KVM arm64 vGICv2 (GICV_DIR INTID handling)Unscored
• Linux x86/tdx: off-by-one GENMASK makes the port I/O value mask one bit too wide in a TDX guestCVE-2026-89751 · Linux kernel x86/tdx (handle_in/handle_out port I/O mask)Unscored
• Linux memcg: concurrent memory.max writers reclaim toward a stale target and can loop indefinitelyCVE-2026-89752 · Linux kernel memcg (memory.high / memory.max writer reclaim loop)Unscored
• Linux mm/vmscan: direct reclaim never reports an RCU-tasks quiescent state, stalling rcu_tasks under memory pressureCVE-2026-89753 · Linux kernel mm/vmscan (shrink_lruvec RCU-tasks quiescent state)Unscored
• Microsoft Hyper-V: vmswitch fails to validate guest OID requestsCVE-2021-28476 · Microsoft Hyper-VCritical