Cloudanix VulnDB

CVE-2026-99125

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how the system tracks performance data on certain IBM mainframe hardware could let a local user cause monitoring features to misbehave or crash the machine.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in s390 perf PMU handling where stop callbacks can be invoked multiple times without state checks, combined with unsafe list iteration and unsupported ioctl usage leading to event_limit misuse.

Why it matters to the business

Performance monitoring on s390 systems can trigger kernel instability or incorrect sampling behavior under high load or task scheduling, increasing operational risk for workloads relying on perf events.

How an attack unfolds

An attacker with local access crafts perf events or ioctls to trigger repeated stop callbacks and event_limit exhaustion on s390, bypassing throttling and causing PAI sample mishandling during task termination.

How to fix it

Apply the kernel patch that adds PERF_HES_STOPPED checks in stop/start, prohibits the unsupported ioctl, and switches to list_for_each_entry_safe; rebuild and reboot affected s390 kernels.

How to confirm the fix worked

Confirm the patched kernel source contains the bit checks and safe iteration; run perf workloads that previously triggered double-stop to verify no repeated callbacks occur.

Typical attack path

  1. Create perf events targeting CRYPTO_ALL or NNPA_ALL
  2. Trigger high sampling load to invoke throttle path
  3. Force scheduler task termination to invoke second stop
  4. Use ioctl to set event_limit and trigger overflow path
  5. Observe or crash via unsafe list iteration in pai_have_samples

How to detect it

Review kernel logs for repeated PMU stop invocations, perf_event_overflow calls under event_limit, and crashes in pai_have_samples or pai_stop on s390 systems.

What your security team should do

  • Prioritize patching s390 systems within the next maintenance window due to recent publication
  • Disable unnecessary perf monitoring on s390 until updated
  • Monitor for perf-related kernel oops in system logs

The record

In the Linux kernel, the following vulnerability has been resolved: s390/pai: Handle multiple PMU stop callback invocations Handle the following scenario: The kernel protects itself against a very high sampling load and throttles the sampling using: perf_event_throttle() --> PMU->stop() Shortly later the scheduler may terminate the task and removes it from the CPU. It again calls PMU->stop() which results in two invocations of PMU->stop() called back to back. Protect against this and check the PERF_HES_STOPPED bit on function entry. If it is already set return. Clear bit PERF_HES_STOPPED in PMU->start(). Prohibit ioctl(fd, PERF_EVENT_IOC_PERIOD, ...) call for this event. It sets perf_event::event_limit to a positive value and causes perf_event_overflow() to invoke pai_stop() call back function when perf_event::event_limit hits zero. This is not supported because the sample events CRYPTO_ALL and NNPA_ALL are only taken at schedule out of a task. Use list_for_each_entry_safe() for safe iteration over syswide_list in pai_have_samples().

Affected packages

Ecosystem Package Introduced Fixed