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().