CVE-2026-97526 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/pai: Support CPU hotplug for PMU PAI
The command 'perf stat -e pai_crypto/CRYPTO_ALL/ -- <command>' crashes the kernel when CPUs are hotplug added during that run.
Root cause is the missing allocation of per-CPU data structures for that new CPU. The allocation is dynamic and the first event that has task context creates such a structure for each online CPU. This is not sufficient. CPUs may be offline during event creation and can be set online during the perf run time. For example commands
# echo 0 > /sys/devices/system/cpu/cpu1/online # perf stat -e cycles -i -- stress-ng -t10s --matrix X # sleep 1 # echo 1 > /sys/devices/system/cpu/cpu1/online
Currently without a CPU hotplug handler, that new CPU has no per-CPU data infrastructure. The scheduler runs PMU call back function pai_add() to install the PMU support for that CPU before the task is being scheduled on that new CPU. In pai_add() instructions
mp = this_cpu_ptr(pai_root[idx].mapptr);
cpump = mp->mapptr;
return a NULL pointer and the result is a kernel panic as variable cpump is used inside that function.
Add CPU hotplug support for CPU add and delete and create the necessary per-CPU data infrastructure during CPU hotplug add processing. Same for CPU hotplug remove. This is done when the CPU is offline to ensure the data structures are available when CPU is made online and tasks are scheduled on it.
[[email protected]: fixup error path in pai_init()]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel vulnerability identified as CVE-2024-s390-pai-hotplug involves a critical flaw within the Performance Monitoring Unit (PMU) Architecture-specific Interface (PAI) subsystem for IBM s390 systems. This issue manifests when CPU hotplugging operations are performed concurrently with performance monitoring events, specifically those utilizing the pai_crypto interface. The root cause lies in the improper initialization and management of per-CPU data structures required by the PAI infrastructure. Under normal circumstances, these data structures are allocated dynamically during event creation for currently online CPUs. However, this approach fails to account for CPUs that transition from an offline state to an online state while a performance monitoring session is active. Consequently, when such a newly activated CPU attempts to execute tasks associated with PMU callbacks, the system lacks the necessary per-CPU context, leading to a null pointer dereference and subsequent kernel panic.
From a technical perspective, the vulnerability stems from the absence of dedicated CPU hotplug handlers within the pai subsystem. The existing implementation relies on lazy initialization triggered by task scheduling events. When a new CPU is brought online during an active perf stat run, the scheduler invokes the pai_add callback to install PMU support for that specific processor. Inside this function, code attempts to retrieve per-CPU pointers using macros such as this_cpu_ptr(pai_root[idx].mapptr) and subsequently accesses mp->mapptr. Because no allocation occurred during the hotplug add phase, these pointers remain null. The subsequent dereference of cpump results in a segmentation fault at kernel level, effectively crashing the entire system. This behavior violates fundamental expectations for resource management in multiprocessor environments where hardware topology changes dynamically.
The operational impact of this vulnerability is severe, primarily categorized as a Denial of Service (DoS) against the host operating system. An attacker or even an automated workload manager capable of triggering CPU hotplug events while performance monitoring tools are running can induce a complete system crash. This disrupts all services hosted on the affected s390 machine and requires manual intervention to reboot, thereby compromising availability. In environments where high availability is critical, such as cloud infrastructure or enterprise data centers utilizing IBM Z systems, this flaw presents a significant risk if administrators utilize performance profiling tools alongside dynamic resource scaling features. The vulnerability affects system stability rather than confidentiality or integrity directly, although the resulting downtime can have cascading effects on business continuity and service level agreements.
This issue aligns with CWE-401, which describes Missing Release of Memory after Effective Lifetime, specifically in the context of missing initialization for dynamically allocated resources tied to hardware states. Furthermore, it relates to CWE-823, Use of Out-of-range Pointer Offset, as the code attempts to access memory through a null pointer due to uninitialized state variables. From an offensive security perspective, this vulnerability can be mapped to MITRE ATT&CK technique T1499, Endpoint Denial of Service, where an adversary leverages system instability to disrupt operations. It also touches upon T1053, Scheduled Task/Job, if the hotplug event is triggered via automated scripts or orchestration tools designed for resource management.
To mitigate this vulnerability, it is imperative that systems running affected versions of the Linux kernel on s390 architecture are updated with patches that implement proper CPU hotplug support within the PAI subsystem. The fix involves adding explicit handlers for both CPU add and delete events to ensure per-CPU data structures are allocated before a processor becomes online and freed appropriately when it goes offline. Administrators should verify their kernel version against vendor advisories from IBM or upstream Linux maintainers. Until patches are applied, operational mitigations include avoiding the simultaneous use of performance monitoring tools like perf stat with CPU hotplug operations. Restricting access to cpu hotplug interfaces for unprivileged users and ensuring that system administrators do not perform topology changes during active profiling sessions can reduce the attack surface. Regularly applying security updates is the most effective long-term strategy to resolve this kernel-level defect.