CVE-2025-22094 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
powerpc/perf: Fix ref-counting on the PMU 'vpa_pmu'
Commit 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa counters") introduced 'vpa_pmu' to expose Book3s-HV nested APIv2 provided L1<->L2 context switch latency counters to L1 user-space via perf-events. However the newly introduced PMU named 'vpa_pmu' doesn't assign ownership of the PMU to the module 'vpa_pmu'. Consequently the module 'vpa_pmu' can be unloaded while one of the perf-events are still active, which can lead to kernel oops and panic of the form below on a Pseries-LPAR:
BUG: Kernel NULL pointer dereference on read at 0x00000058 <snip> NIP [c000000000506cb8] event_sched_out+0x40/0x258
LR [c00000000050e8a4] __perf_remove_from_context+0x7c/0x2b0
Call Trace: [c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (unreliable)
[c00000025fc3fc80] [fffffffffffffee0] 0xfffffffffffffee0
[c00000025fc3fcd0] [c000000000501e70] event_function+0xa8/0x120
<snip> Kernel panic - not syncing: Aiee, killing interrupt handler!
Fix this by adding the module ownership to 'vpa_pmu' so that the module 'vpa_pmu' is ref-counted and prevented from being unloaded when perf-events are initialized.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability described in CVE-2025-22094 represents a critical reference counting flaw within the Linux kernel's powerpc/perf subsystem, specifically affecting the vpa_pmu PMU implementation. This issue emerges from the introduction of the vpa_pmu module in the Book3s-HV nested APIv2 framework, which was designed to expose L1-to-L2 context switch latency counters to user-space applications through perf-events. The flaw manifests when the module lacks proper ownership assignment to the vpa_pmu PMU, creating a dangerous race condition where the module can be unloaded while perf-events remain active, leading to kernel oops and potential system panics.
The technical root cause of this vulnerability lies in the improper module reference counting mechanism within the powerpc/perf subsystem. When the vpa_pmu module is loaded, it registers a PMU interface to expose performance counters, but fails to establish proper ownership relationships that would prevent the module from being unloaded during active usage. This design oversight creates a scenario where perf-event subsystem can attempt to access memory locations that have already been freed when the module is unloaded, resulting in NULL pointer dereferences. The kernel panic occurs during the event scheduling process when the event_sched_out function attempts to access a freed memory location at offset 0x00000058, specifically in the event_function handler that is part of the perf-event processing pipeline.
The operational impact of this vulnerability is severe, particularly in Pseries-LPAR environments where the Book3s-HV hypervisor is utilized for nested virtualization. System administrators and operators running these configurations face the risk of unexpected system crashes and complete service interruptions when perf-events are actively monitoring the vpa_pmu counters. The vulnerability affects the stability and reliability of enterprise-grade systems, potentially causing data loss and extended downtime during critical operations. The panic mechanism described in the kernel logs indicates that the system cannot recover gracefully from the NULL pointer dereference, leading to immediate system termination as the kernel attempts to protect itself from further corruption.
The fix implemented addresses this vulnerability by properly assigning module ownership to the vpa_pmu PMU, thereby establishing proper reference counting mechanisms that prevent premature module unloading. This solution aligns with the principles of secure kernel module design and follows established practices for managing module lifecycle in kernel space. The fix ensures that when perf-events are initialized and using the vpa_pmu interface, the module will remain loaded until all associated perf-events are properly closed and cleaned up. This approach prevents the race condition that led to the kernel oops and panic, maintaining system stability while preserving the intended functionality of exposing performance counters to user-space applications. This vulnerability demonstrates the importance of proper module ownership and reference counting in kernel subsystems, particularly those dealing with performance monitoring and event handling, and reflects common patterns seen in CWE-476 (NULL Pointer Dereference) and ATT&CK techniques related to kernel exploitation and system stability compromise.