CVE-2026-97925

tick/broadcast: Plug clockevents replacement race

N/A
Published: September 25, 2026 at 10:22 AM UTC
Updated: October 19, 2026 at 10:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: tick/broadcast: Plug clockevents replacement race 朱恺乾 reported and decoded the following race condition when a broadcast device is replaced: CPUA CPUB __tick_broadcast_oneshot_control() bc = tick_broadcast_device.evtdev; tick_install_broadcast_device(dev) clockevents_exchange_device(cur, dev) shutdown(cur); detach(cur); cur->handler = noop; tick_broadcast_device.evtdev = dev; tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device. If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state. The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations. The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation. That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock. Let clockevents_exchange_device() do both operations as before, but let the broadcast device code take the two step approach and do the device exchange under tick_broadcast_lock and drop the module reference count after releasing it.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

2.6.21f8381cba04ba8173fd5a2b8e5cd8b3290ee13a98
Vendor states this is fixed in 113a9796effe3376d2ec5aabcca1fef4fef4cd62 (fixed)
Vendor states this is fixed in 292b7a8ed84032cfdfc9076a690360f7d3f640d4 (fixed)
Vendor states this is fixed in 338d6859cd1580617807290f6d7e92b1662d4695 (fixed)
Vendor states this is fixed in 3525b94b2f258e0b99d1ee5a82a80b51bc1cc818 (fixed)
Vendor states this is fixed in 3da55616db2b6b7d9caa3b7ff1e8983224e0ed52 (fixed)
Vendor states this is fixed in 757aa9f548c18b96da1d56d11f65be8188a16d59 (fixed)
Vendor states this is fixed in 2.6.21 (unaffected)
Vendor states this is fixed in 6.1.189 (unaffected)
Vendor states this is fixed in 6.12.111 (unaffected)
Vendor states this is fixed in 6.18.53 (unaffected)
Vendor states this is fixed in 6.6.158 (unaffected)
Vendor states this is fixed in 7.2.7 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc3 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card