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
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.