CVE-2025-39821

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Avoid undefined behavior from stopping/starting inactive events<br /> <br /> Calling pmu-&gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can<br /> leave event-&gt;hw.idx at -1. When PMU drivers later attempt to use this<br /> negative index as a shift exponent in bitwise operations, it leads to UBSAN<br /> shift-out-of-bounds reports.<br /> <br /> The issue is a logical flaw in how event groups handle throttling when some<br /> members are intentionally disabled. Based on the analysis and the<br /> reproducer provided by Mark Rutland (this issue on both arm64 and x86-64).<br /> <br /> The scenario unfolds as follows:<br /> <br /> 1. A group leader event is configured with a very aggressive sampling<br /> period (e.g., sample_period = 1). This causes frequent interrupts and<br /> triggers the throttling mechanism.<br /> 2. A child event in the same group is created in a disabled state<br /> (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.<br /> Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&gt;hw.idx remains<br /> initialized at -1.<br /> 3. When throttling occurs, perf_event_throttle_group() and later<br /> perf_event_unthrottle_group() iterate through all siblings, including<br /> the disabled child event.<br /> 4. perf_event_throttle()/unthrottle() are called on this inactive child<br /> event, which then call event-&gt;pmu-&gt;start()/stop().<br /> 5. The PMU driver receives the event with hw.idx == -1 and attempts to<br /> use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),<br /> leading to the UBSAN report.<br /> <br /> The throttling mechanism attempts to start/stop events that are not<br /> actively scheduled on the hardware.<br /> <br /> Move the state check into perf_event_throttle()/perf_event_unthrottle() so<br /> that inactive events are skipped entirely. This ensures only active events<br /> with a valid hw.idx are processed, preventing undefined behavior and<br /> silencing UBSAN warnings. The corrected check ensures true before<br /> proceeding with PMU operations.<br /> <br /> The problem can be reproduced with the syzkaller reproducer: