CVE-2025-22094: powerpc/perf: Fix ref-counting on the PMU 'vpa_pmu'
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.
Security readout for executives and security teams
Plain-English summary
A Linux kernel flaw can crash certain IBM Power pSeries virtual machines when the vpa_pmu module is unloaded while related performance-monitoring events remain active. The supplied record rates it high severity. The demonstrated consequence is a kernel panic and service interruption; broader confidentiality or integrity impact is not established by the technical description.
Executive priority
Prioritize affected PowerPC virtualization hosts where local users or monitoring tooling can access these counters. Patch during the next expedited maintenance window, sooner for availability-critical shared systems. General Linux fleets outside the described PowerPC pSeries configuration are unlikely to be exposed based on the supplied evidence.
Technical view
The vpa_pmu performance-monitoring unit lacks module ownership introduced with commit 176cda0619b6. Consequently, active perf events do not retain the module reference, permitting unload and later NULL-pointer dereference during event scheduling. The fix assigns ownership so reference counting prevents unloading while events remain initialized.
Likely exposure
Exposure appears limited to affected Linux kernels on PowerPC pSeries LPAR systems using Book3s-HV nested APIv2 counters through vpa_pmu. Triggering requires local, low-privileged access and an active perf event during module unloading. The supplied version data references 6.13 through 6.15 but does not clearly define every affected range.
Exploitation context
The CVSS 3.1 score is 7.3 with local access, low privileges, low complexity, and user interaction. The supplied record is not in KEV, and no supplied source reports active exploitation. Evidence demonstrates a NULL-pointer dereference and kernel panic, primarily supporting local denial-of-service risk.
Researcher notes
The root cause is missing PMU module ownership and therefore incorrect lifetime management. The record supplies three stable-kernel fix commits but no complete branch-to-version mapping. Researchers should verify backports by commit content rather than version assumptions. The panic trace supports availability impact; the supplied description does not independently demonstrate data disclosure, modification, or remote reachability.
Mitigation direction
Upgrade to a vendor-supported kernel containing the applicable referenced stable fix.
Until updated, prevent vpa_pmu unloading while its perf events may remain active.
Restrict local access and module-management privileges on affected PowerPC systems.
Consult distribution guidance for exact fixed package versions and reboot requirements.
Validation and detection
Inventory PowerPC pSeries LPAR hosts and record their running kernel versions.
Determine whether vpa_pmu and Book3s-HV nested APIv2 performance counters are used.
Confirm the installed kernel contains the applicable referenced stable fix.
Safely verify that active vpa_pmu events retain module ownership and block unloading.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-22094 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.