CVE-2026-89547: SUNRPC: Check svc pool percpu counter allocation
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Check svc pool percpu counter allocation
svccreate() initializes three per-pool percpucounter stats and ignores every return value. On SMP, percpucounterinit() fails when allocpercpugfp() cannot satisfy the allocation, leaving the failed counter with fbc->counters == NULL and its embedded rawspinlockt, listhead, and count never initialized. svccreate() returns the half-constructed svcserv to nfsd, lockd, or the NFS callback service anyway.
Once that service is live, the hot-path increments in svcxprtenqueue(), svchandlexprt(), and svcpoolwakeidlethread() 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/poolstats read walks the same NULL per-cpu storage and returns garbage, and on CONFIGDEBUGSPINLOCK 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 percpucounterinit() return value in svccreate() 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 percpucounterdestroy() per counter at teardown frees each per-cpu allocation exactly once.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Operational
In __svc_create(), check the return value of each percpu_counter_init(); if an allocation fails, fail service creation and unwind counters already initialized in the current pool and every previously initialized pool.
- Operational
At teardown, call percpu_counter_destroy() once for each per-pool percpu counter so each per-CPU allocation is freed exactly once.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Exposure requires an RPC server service such as nfsd, lockd, or the NFS callback service to be created after a per-CPU allocation failure. The described failure condition is reachable only by a local administrator during RPC server startup.
What would an attacker need to trigger the vulnerable state?
An attacker would need local administrative capability and would need to cause a per-CPU allocation to fail while the RPC server is starting. The affected service may then be returned in a partially constructed state and become live.
How can administrators tell whether the failure has occurred?
Reading /proc/fs/nfsd/pool_stats may return garbage. Systems built with CONFIG_DEBUG_SPINLOCK or lockdep may also report a warning involving an uninitialized lock; otherwise, hot-path counter operations can silently corrupt per-CPU data.