CVE-2026-53180
Received Received - Intake
Linux Kernel Timer Livelock Vulnerability

Publication date: 2026-06-25

Last updated on: 2026-06-25

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: timers/migration: Fix livelock in tmigr_handle_remote_up() tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu == smp_processor_id(), 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 run_timer_base(BASE_GLOBAL) and before tmigr_handle_remote() 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 fetch_next_timer_interrupt_remote() 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 timer_expire_remote() unconditionally. That's minimal overhead for the common case as __run_timer_base() returns immediately if there is nothing to expire in the local wheel. [ tglx: Amend change log and add a comment ]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-25
Last Modified
2026-06-25
Generated
2026-06-25
AI Q&A
2026-06-25
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's timer migration code. Specifically, the function tmigr_handle_remote_cpu() incorrectly assumes that the local CPU's timers have already been handled, so it skips calling timer_expire_remote() when the CPU is the same as the current processor. However, this assumption is incorrect because the system time (jiffies) can advance between handling the local timers and evaluating remote timers.

As a result, a timer that expires after the local timer wheel has advanced but before the remote handling is evaluated can be ignored. This means the timer's callback is never invoked and the timer is never removed from the timer wheel.

Worse, the function fetch_next_timer_interrupt_remote() continues to report this timer as expired and re-queues the event repeatedly with the same expiration time, causing an indefinite spinning loop (livelock).

The fix involves always calling timer_expire_remote() unconditionally to ensure expired timers are handled properly, preventing the livelock.

Impact Analysis

This vulnerability can cause a livelock situation in the Linux kernel where expired timers are never properly handled and callbacks are never invoked. This can lead to system performance degradation or unresponsiveness because the kernel is stuck in a loop handling the same expired timer repeatedly.

Such a livelock can affect system stability and reliability, potentially impacting any applications or services relying on timely timer callbacks.

Mitigation Strategies

The vulnerability has been resolved in the Linux kernel by fixing the timer migration code to call timer_expire_remote() unconditionally, preventing the livelock condition.

To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes this fix.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53180. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart