CVE-2026-89549
nicheNFS connection hangs in Linux kernel sunrpc when pools outnumber threads
A flaw in the Linux kernel's sunrpc pool routing can leave NFS server (nfsd) client connections hanging indefinitely. When a service runs with fewer threads than it has pools — e.g., nfsd configured with fewer threads than the host has NUMA nodes while in 'pernode' or 'percpu' mode — the trailing pools have no threads, and any transport routed to such a pool is queued but never serviced, so the connection hangs forever. Because a remote, unauthenticated client connection landing on a threadless pool triggers the hang, this is an availability issue (CVSS 7.5, A:H), and accumulated hung transports can degrade the NFS service on the affected host. Affected systems are Linux servers running sunrpc-based services (primarily nfsd, and potentially lockd) in pernode/percpu pool mode with thread counts below the pool count — a configuration typical of large multi-NUMA enterprise and HPC servers. No public proof of concept exists, the flaw is not in the CISA KEV catalog, and no in-the-wild exploitation is known.
What to do: Update to a kernel containing the svc_pool_for_cpu() fix once your distro ships it. Meanwhile, on multi-NUMA NFS servers either raise the nfsd thread count above the number of NUMA nodes/CPU pools or switch sunrpc pool_mode to 'global' (e.g., /sys/module/sunrpc/parameters/pool_mode). Watch for NFS client connections stuck in an established-but-unresponsive state and restart nfsd to recover hung transports.
| Linux kernel (sunrpc subsystem, used by nfsd and other sunrpc services) | Exact version ranges not enumerated in the provided data; affected are kernels prior to the fix that makes svc_pool_for_cpu() skip pools with no threads — confi |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: sunrpc: route to a populated pool in svc_pool_for_cpu() svc_set_num_threads() spreads the requested threads evenly across the service's pools (base = nrservs / sv_nrpools). When a service runs fewer threads than it has pools -- e.g. an nfsd configured with fewer threads than the host has NUMA nodes while running in "pernode" or "percpu" mode -- the trailing pools are left with no threads at all. svc_xprt_enqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's sp_xprts, and only wakes a thread from the same pool. Each thread services exclusively its own pool, so a transport that lands on a threadless pool is enqueued on sp_xprts and never picked up: the connection hangs indefinitely. Have svc_pool_for_cpu() skip pools that currently have no threads, falling back to the next populated pool. This trades NUMA locality for a guarantee that the work is actually serviced. sp_nrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with data_race().
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.