CVE-2026-89547

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.