CVE-2026-89549
High · 7.5CVSS
7.5
EPSS
0.7%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel bug can cause some network connections used by file sharing and similar services to get stuck forever when the service is configured with too few worker threads for the hardware.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability allows RPC transports to be routed via svc_pool_for_cpu() to service pools that have zero threads (sp_nrthreads == 0), causing the transport to be enqueued on sp_xprts with no thread ever waking to service it, resulting in indefinite connection hangs.
Why it matters to the business
Networked services such as NFS can experience partial or total unavailability for clients whose requests land on empty pools, leading to application timeouts, stalled operations, and unplanned downtime in environments using per-node or per-CPU thread modes.
How an attack unfolds
An attacker establishes an RPC connection that is assigned by svc_xprt_enqueue() to a CPU whose associated pool has no threads; the transport is queued but never dequeued, causing the connection to hang without any further attacker action required.
How to fix it
Upgrade the Linux kernel to a version containing the fix for svc_pool_for_cpu() that routes to the next populated pool; apply the patch that adds the empty-pool check and data_race() annotation.
How to confirm the fix worked
Confirm the running kernel contains the commit titled "sunrpc: route to a populated pool in svc_pool_for_cpu()"; test by configuring fewer threads than pools and verifying that connections complete instead of hanging.
Typical attack path
- Identify or trigger a Linux kernel RPC service (e.g., nfsd) configured with fewer threads than NUMA nodes or CPUs in pernode/percpu mode
- Send legitimate RPC requests that are directed by the scheduler to a CPU mapped to an empty pool
- Observe the transport remain permanently enqueued on sp_xprts with no servicing thread
How to detect it
Search system and RPC service logs for stalled connections or hung threads; inspect svc_pool structures via kernel debug or tracing for pools reporting zero threads while still receiving enqueues; correlate with NUMA-aware thread allocation events.
What your security team should do
- Prioritize kernel updates on all systems running RPC services in multi-pool configurations
- Review nfsd or equivalent service thread counts against NUMA topology and increase threads if necessary as a temporary mitigation
- Monitor service logs and connection states for indefinite hangs until patches are deployed
The record
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().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|