CVE-2026-80626 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del
fsl_emb_pmu_del() unconditionally calls put_cpu_var(cpu_hw_events) at the 'out:' label, but only calls the matching get_cpu_var() after the 'i < 0' early-return check. When event->hw.idx is negative the function jumps to 'out:' without having taken get_cpu_var(), and the trailing put_cpu_var() then issues an unmatched preempt_enable(), underflowing preempt_count.
On a CONFIG_PREEMPT=y kernel preempt_count would underflow and eventually present as a 'scheduling while atomic' BUG.
Move put_cpu_var() to pair with get_cpu_var() so the percpu access is correctly bracketed and the 'out:' label only handles perf_pmu_enable.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in the Linux kernel, specifically within the powerpc performance monitoring unit driver for Freescale embedded systems, represents a critical logic error in resource management that leads to preempt count underflow. This issue resides in the fsl_emb_pmu_del function, which is responsible for removing or disabling hardware performance counters associated with a specific CPU core. The root cause of this vulnerability lies in an asymmetrical handling of per-CPU variable access locks. In Linux kernel development, functions like get_cpu_var and put_cpu_var are used to safely access data structures that reside on the local processor's memory space while preventing preemption during critical sections. The code path within fsl_emb_pmu_del fails to maintain this balance under specific error conditions. Specifically, when a hardware index is found to be negative, indicating an invalid or out-of-bounds request, the function jumps directly to an exit label labeled 'out'. However, in this early-exit scenario, the corresponding get_cpu_var call that was intended to secure the per-CPU context has not been executed. Consequently, the unconditional execution of put_cpu_var at the end of the function results in a preempt_disable counter being decremented without a prior increment. This mismatch causes the kernel's internal preemption count for that CPU to underflow, dropping below zero and corrupting the scheduler state.
The operational impact of this vulnerability is severe, particularly on kernels configured with CONFIG_PREEMPT enabled, which allows tasks to be interrupted at more points in the code path for improved responsiveness. When the preempt_count underflows due to the unmatched put_cpu_var call, it triggers a kernel panic known as 'scheduling while atomic'. This BUG occurs because the scheduler detects that an attempt is being made to schedule or switch contexts while the CPU is still holding locks or inside a non-preemptible section, which violates fundamental concurrency safety rules. In practice, this manifests as a system crash or immediate halt of the affected processor core, leading to a denial of service for any workloads running on that specific CPU. For systems relying on high availability and continuous performance monitoring, such as those in financial trading platforms or real-time industrial control systems, this instability can result in significant downtime and data loss. The vulnerability is exploitable by local users who have the ability to trigger perf events with invalid hardware indices, effectively allowing a malicious actor to crash the system if they possess sufficient privileges to interact with the performance monitoring subsystem.
From a classification perspective, this flaw aligns closely with CWE-672, which describes the use of operations on variables or resources after their intended lifetime has ended, specifically in the context of resource management and locking mechanisms where the lock is released without being acquired. It also relates to CWE-401, missing release of a resource after successful acquisition, although here it is more accurately characterized as an unbalanced acquire-release sequence leading to state corruption. In terms of adversarial tactics, this vulnerability can be leveraged within the MITRE ATT&CK framework under Tactic TA0005, Defense Evasion, specifically through techniques that cause system instability or denial of service to disrupt monitoring capabilities or crash security agents. It may also fall under Impact categories such as Availability impact, where an attacker aims to make a resource unavailable to its intended users by causing the operating kernel to panic.
Mitigation strategies for this vulnerability primarily involve applying the upstream Linux kernel patch that corrects the control flow within fsl_emb_pmu_del. The fix involves restructuring the function so that put_cpu_var is only called when it has a corresponding get_cpu_var, ensuring that per-CPU access is correctly bracketed. For systems where immediate patching is not feasible, administrators should restrict access to performance monitoring tools like perf or bpf to trusted users with high privileges, thereby reducing the attack surface for local privilege escalation or denial-of-service attempts. Additionally, enabling kernel hardening features such as PREEMPT_VOLUNTARY_DEBUG can help detect similar locking imbalances during development and testing phases before deployment. Regularly updating the Linux kernel on PowerPC-based systems is essential to ensure that these concurrency bugs are resolved, maintaining both system stability and security posture against local exploitation attempts targeting low-level hardware abstraction layers.