CVE-2026-64070: powerpc/hv-gpci: fix preempt count leak in sysfs show paths
In the Linux kernel, the following vulnerability has been resolved:
powerpc/hv-gpci: fix preempt count leak in sysfs show paths
Four sysfs show() callbacks in hv-gpci take getcpuvar(hvgpcireqb) (which calls preemptdisable()) but only call the matching putcpuvar() on the error path under the 'out:' label. Every successful read leaks one preemptdisable():
processorbustopologyshow() processorconfigshow() affinitydomainviavirtualprocessorshow() affinitydomainviadomainshow()
(affinitydomainviapartitionshow() was already correct.)
On a CONFIGPREEMPT=y kernel, repeated reads raise preemptcount and eventually return to userspace with preemption still disabled. The next user-mode page fault then hits faulthandlerdisabled() == 1, gets forced to SIGSEGV, and the resulting coredump trips 'BUG: scheduling while atomic' in callusermodehelperexec -> waitforcompletionstate -> schedule:
BUG: scheduling while atomic: <task>/<pid>/0x00000004 ... schedulebug+0x6c/0x90 schedule+0x58c/0x13a0 schedule+0x48/0x1a0 scheduletimeout+0x104/0x170 waitforcompletionstate+0x16c/0x330 callusermodehelperexec+0x254/0x2d0 vfscoredump+0x1050/0x2590 getsignal+0xb9c/0xc80 donotifyresume+0xf8/0x470
Add an outsuccess label that calls putcpuvar() before returning the byte count, mirroring affinitydomainviapartitionshow().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Fix the hv-gpci sysfs show paths so every get_cpu_var(hv_gpci_reqb) is matched by put_cpu_var(), including successful reads and the error path; add an out_success label that calls put_cpu_var() before returning, covering affinity_domain_via_domain_show(), affinity_domain_via_virtual_processor_show(), processor_bus_topology_show(), and processor_config_show().
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects Linux kernel systems using the powerpc hv-gpci code, specifically the four affected sysfs show callbacks. The described failure requires a kernel built with CONFIG_PREEMPT=y.
What does an attacker or local user need to do to trigger the failure?
A local user needs to repeatedly read one of the affected hv-gpci sysfs attributes. Each successful read leaks a preemption disable count; after enough reads, a subsequent user-mode page fault can be forced to SIGSEGV and may produce a “scheduling while atomic” kernel bug during coredump handling.
Is this a remote issue?
No. The supplied CVSS vector identifies local access (AV:L) and low privileges (PR:L), with no user interaction required (UI:N).
How can administrators recognize that the system may already be affected?
Relevant symptoms include processes receiving SIGSEGV after repeated reads of the affected sysfs paths and kernel logs containing “BUG: scheduling while atomic” during coredump processing. The call trace may include call_usermodehelper_exec, vfs_coredump, and get_signal.
What remediation is available?
A patch is available. Apply the referenced stable kernel fixes, which ensure the successful sysfs read paths also call the matching put_cpu_var() and do not leak the preemption count.