CVE-2026-99125: s390/pai: Handle multiple PMU stop callback invocations

Published Oct 28, 2026

Updated

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:

perfeventthrottle() --> 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 PERFHESSTOPPED bit on function entry. If it is already set return. Clear bit PERFHESSTOPPED in PMU->start().

Prohibit ioctl(fd, PERFEVENTIOCPERIOD, ...) call for this event. It sets perfevent::eventlimit to a positive value and causes perfeventoverflow() to invoke paistop() call back function when perfevent::eventlimit hits zero. This is not supported because the sample events CRYPTOALL and NNPAALL are only taken at schedule out of a task.

Use listforeachentrysafe() for safe iteration over syswidelist in paihavesamples().

Affected Software

1 affected component

Linux Linux kernel

Event History

Oct 28, 2026

CVE Published

via MITRE·10:34 AM

Data Sourced

via MITRE·10:34 AM

Description

Data Sourced

via NVD·11:17 AM

Description

Frequently Asked Questions

Which systems and workloads are relevant to this issue?

The issue is specific to the Linux kernel's s390 Processor Activity Instrumentation (PAI) perf PMU path. It is relevant when sampling is throttled under very high load and the sampled task is then terminated or scheduled off the CPU.

What sequence causes the problematic callback behavior?

perf_event_throttle() can invoke the PMU stop callback to throttle sampling. If the scheduler soon removes or terminates that task, it can invoke the same stop callback again, resulting in back-to-back stop operations.

Are period changes supported for the affected sample events?

No. PERF_EVENT_IOC_PERIOD is prohibited for these events because setting a positive event limit can cause perf_event_overflow() to invoke the PAI stop callback when the limit reaches zero; CRYPTO_ALL and NNPA_ALL samples are only taken when a task is scheduled out.

What safeguards does the resolution add?

The stop path returns immediately if PERF_HES_STOPPED is already set, and the start path clears that bit. The change also uses safe iteration for the syswide_list in pai_have_samples().

CVE-2026-99125: s390/pai: Handle multiple PMU stop callback invocations

Affected Software

Event History

Frequently Asked Questions

Which systems and workloads are relevant to this issue?

What sequence causes the problematic callback behavior?

Are period changes supported for the affected sample events?

What safeguards does the resolution add?

Company

Resources

Contact

Frequently Asked Questions

Which systems and workloads are relevant to this issue?

What sequence causes the problematic callback behavior?

Are period changes supported for the affected sample events?

What safeguards does the resolution add?