SUNRPC: Check svc pool percpu counter allocation
Published Sep 11, 2026 · Updated Sep 11, 2026
In the Linux kernel, the following vulnerability has been resolved:
Summary
What happened
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Check svc pool percpu counter allocation
__svc_create() initializes three per-pool percpu_counter stats and ignores every return value. On SMP, percpu_counter_init() fails when __alloc_percpu_gfp() cannot satisfy the allocation, leaving the failed counter with fbc->counters == NULL and its embedded raw_spinlock_t, list_head, and count never initialized. __svc_create() returns the half-constructed svc_serv to nfsd, lockd, or the NFS callback service anyway.
Once that service is live, the hot-path increments in svc_xprt_enqueue(), svc_handle_xprt(), and svc_pool_wake_idle_thread() reach a counter whose backing pointer is NULL. The pointer is a per-cpu offset, so the access does not fault: it resolves to offset zero of the current CPU's per-cpu area and silently corrupts whatever variable lives there. A /proc/fs/nfsd/pool_stats read walks the same NULL per-cpu storage and returns garbage, and on CONFIG_DEBUG_SPINLOCK or lockdep it splats on the never-initialized lock.
Creating the broken service requires a percpu allocation failure during RPC server startup, so it is reachable only by a local administrator under memory pressure or fault injection; a remote peer cannot induce the bad state on its own.
Check each percpu_counter_init() return value in __svc_create() and fail when an allocation fails, unwinding the counters already set up in the current pool and in every pool initialized before it. A discrete percpu_counter_destroy() per counter at teardown frees each per-cpu allocation exactly once.
The record
- CVE
- CVE-2026-89547
- Published
- Sep 11, 2026
- Updated
- Sep 11, 2026
- Vendor
- The Linux Kernel Organization
- Product
- Linux
- Classifications
- Unavailable
- Attack vector
- Unavailable
- Privileges
- Unavailable
Timeline
How it unfolded
- Sep 11, 2026CVE publishedPublication date reported by the CVE source.
- Sep 11, 2026Record updatedLatest update available in the CVE record.
Exploitability
Present is not the same as exploitable
Compare your product and version with the public record. A matching version still requires validation against your environment.
Is a vulnerable build present?
Compare these published version ranges with your installed build and any vendor patches.
- Affected versionversion=6.3
- Affected versionversion=ccf08bed6e7a80519569456edd2ea21b7b1701c6 <3a2b7649de76376a69f1d3ed2a539fb15907cd4d
- Affected versionversion=ccf08bed6e7a80519569456edd2ea21b7b1701c6 <43e11e164704dde975c9edb370de1a06bec67270
- Affected versionversion=ccf08bed6e7a80519569456edd2ea21b7b1701c6 <b541a15046976e481618726cc23db0fb22d576db
- Affected versionversion=ccf08bed6e7a80519569456edd2ea21b7b1701c6 <bd1ef2cfb44d72b7aa6943e87b206eb0e30fbd0c
What conditions does exploitation require?
What is affected?
Published CVSS scores
No CVSS assessment is available in this record.
CVSS describes severity. EPSS estimates exploitation probability.
Attacks
What attackers are doing with it
Daily unique IPs observed by Shadowserver honeypots for known exploited vulnerabilities (KEVs). Missing observations do not establish an absence of attacks.
Weakness, pattern, technique
No sourced classifications are available.
Public exploit references
No public exploit references are available in this record.
Labels summarize the accepted research assessment. They do not indicate a test against your environment.
Technologies
Your stack
See the directory against your own environment.
Your stack
Check the software in your environment
Book a demo to see how Hinoki identifies affected software and validates exploitability in your environment.
Book a demo