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 ]
Published: 2026-06-25
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel contained a livelock in the timer migration routine tmigr_handle_remote_up that caused a continuous loop when’s local timer wheel advanced. The callback never fired and the event was repeatedly re‑queued, consuming 100 % CPU time and preventing the system from servicing other tasks. This condition results in a denial of service, as the affected CPU cannot process normal kernel operations while trapped in the loop.

Affected Systems

All Linux kernel releases that include the timers/migration code before the recent patch are potentially affected. The public kernel commits linked in the references contain the fix, meaning any system running a kernel built from source that predates those changes could be impacted.

Risk and Exploitability

The exploitability is limited to conditions where timers expire after a local timer wheel advancement; therefore, the attack surface is moderate and likely requires the ability to generate timer activity or influence kernel scheduling. EPSS data is not available, and the vulnerability is not listed in CISA KEV, indicating that no publicly documented exploit is known. However, because the bug can cause a persistent CPU lockup, the risk to system availability remains significant, especially in high‑availability deployments.

Generated by OpenCVE AI on June 25, 2026 at 11:59 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update your Linux kernel to a release that includes the livelock fix (commit 07b3b83587fb or later). The latest stable kernel already contains this change.
  • Reboot the system after updating to load the corrected kernel.
  • For custom kernel builds, cherry‑pick the commit that applies the change or rebuild from a source tree that includes the patch.

Generated by OpenCVE AI on June 25, 2026 at 11:59 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 25 Jun 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665
CWE-835

Thu, 25 Jun 2026 09:15:00 +0000

Type Values Removed Values Added
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 ]
Title timers/migration: Fix livelock in tmigr_handle_remote_up()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-25T08:38:55.332Z

Reserved: 2026-06-09T07:44:35.390Z

Link: CVE-2026-53180

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-25T12:00:14Z

Weaknesses
  • CWE-665

    Improper Initialization

  • CWE-835

    Loop with Unreachable Exit Condition ('Infinite Loop')