CVE-2026-89549: sunrpc: route to a populated pool in svc_pool_for_cpu()
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: route to a populated pool in svcpoolforcpu()
svcsetnumthreads() spreads the requested threads evenly across the service's pools (base = nrservs / svnrpools). 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.
svcxprtenqueue() selects a pool from the CPU servicing the transport, queues the transport on that pool's spxprts, 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 spxprts and never picked up: the connection hangs indefinitely.
Have svcpoolforcpu() 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. spnrthreads is only updated under the service mutex; the lockless read here is a best-effort routing hint, so annotate it with datarace().
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems running an RPC service such as nfsd in "pernode" or "percpu" pool mode can be exposed when the configured service thread count is lower than the number of service pools, such as when there are fewer threads than NUMA nodes.
What condition triggers the service disruption?
A transport must be assigned to a pool with no service threads. Because workers only service their own pool, the transport remains queued in that pool and its connection can hang indefinitely.
Is this a default-configuration issue?
The provided information identifies the issue only when a service uses "pernode" or "percpu" mode and has fewer threads than pools. It does not state whether those modes or thread counts are default settings.
What mitigation is available if the fix cannot be applied immediately?
Configure the service with at least as many threads as its number of pools, avoiding trailing pools with zero threads. The affected scenario is specifically described as having fewer service threads than pools.
How can administrators recognize that they are affected?
Look for RPC transports or connections that are queued but never serviced, resulting in connections hanging indefinitely. The relevant configuration pattern is a service with threadless pools in "pernode" or "percpu" mode.