CVE-2026-53180: timers/migration: Fix livelock in tmigr_handle_remote_up()
In the Linux kernel, the following vulnerability has been resolved:
timers/migration: Fix livelock in tmigrhandleremoteup()
tmigrhandleremotecpu() skips timerexpireremote() when cpu == smpprocessorid(), assuming the local softirq path already handled this CPU's timers.
This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in runtimerbase(BASEGLOBAL) and before tmigrhandleremote() evaluates the expiry times.
As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel.
What's worse is that fetchnexttimerinterruptremote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely.
Fix this by calling timerexpireremote() unconditionally. That's minimal overhead for the common case as runtimerbase() returns immediately if there is nothing to expire in the local wheel.
[ tglx: Amend change log and add a comment ]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Fix the livelock by calling timer_expire_remote() unconditionally in the remote timer handling path (timer_expire_remote() should not be skipped when evaluating timer expiry/livelock conditions).
Linux kernel timer handling call timer_expire_remote() = unconditionally
Event History
Frequently Asked Questions
What is the practical impact if the condition is triggered?
A timer callback may never run and the timer may remain on the timer wheel. The timer-migration handling loop can then repeatedly re-queue an already expired event and spin indefinitely, causing a denial of service.
What level of access does the severity data indicate is required?
The supplied vector rates this as network-accessible with low attack complexity and no privileges or user interaction required. It indicates availability impact only; confidentiality and integrity impacts are listed as none.
What is the available remediation guidance?
Update to a Linux kernel build that includes the referenced fix. The provided data does not identify affected or fixed kernel version numbers.