Answer in brief
CVE-2026-89549 records a Unknown severity vulnerability in sunrpc: route to a populated pool in svc_pool_for_cpu(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=bfd241600a3b0db4fe43c859f1460d0a958d924a <011479cf9a7657d4a3e7cc42a784ac63df594170 || >=bfd241600a3b0db4fe43c859f1460d0a958d924a <9d04d64ad192439835ed9884d767353061c3ed6f || >=bfd241600a3b0db4fe43c859f1460d0a958d924a <8f766d2d0b4dabf54f8b35812df2b4f481d13316 || >=bfd241600a3b0db4fe43c859f1460d0a958d924a <f6310491c4cdb88af73aa551ec9df1f10a90c709 | 011479cf9a7657d4a3e7cc42a784ac63df594170, 9d04d64ad192439835ed9884d767353061c3ed6f, 8f766d2d0b4dabf54f8b35812df2b4f481d13316, f6310491c4cdb88af73aa551ec9df1f10a90c709 |
| Linux/Linuxgeneric | 2.6.19 | Not reported |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 11, 2026
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().
Quoted source text, attributed separately from HOL analysis.