Skip to main content

Linux Kernel CVE-2026-53180

| EUVDEUVD-2026-39271 HIGH
Improper Locking (CWE-667)
2026-06-25 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-gfr2-q5q8-v55v
7.5
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

Internally-triggered timer-migration timing race with no attacker-controlled network input, so AV:L and AC:H; needs local execution driving timer/idle activity (PR:L); pure availability hang (A:H).

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
4.7 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
5.5 MEDIUM
qualitative

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 28, 2026 - 09:23 vuln.today
CVSS changed
Jun 28, 2026 - 08:22 NVD
7.5 (HIGH)
Patch available
Jun 25, 2026 - 10:32 EUVD
CVE Published
Jun 25, 2026 - 09:16 cve.org
UNKNOWN (no severity yet)
CVE Published
Jun 25, 2026 - 09:16 cve.org
HIGH 7.5

DescriptionCVE.org

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 ]

AnalysisAI

Denial of service in the Linux kernel timer migration subsystem allows the global timer hierarchy to enter an indefinite livelock, hanging the affected CPU. The flaw is in tmigr_handle_remote_up(), where tmigr_handle_remote_cpu() skipped timer_expire_remote() for the local CPU on the assumption that the softirq path already serviced its timers; when jiffies advance between local timer processing and remote evaluation, a newly expired timer is never run and is re-queued with expires==now, spinning the goto-again loop forever. The CVSS 3.1 base score is 7.5 (availability only) but EPSS is just 0.18% (7th percentile), there is no public exploit identified at time of analysis, and the issue is not in CISA KEV.

Technical ContextAI

The bug lives in the kernel's hierarchical timer migration (timers/migration) code, which lets idle CPUs offload servicing of other CPUs' global timers so the system can stay in deeper idle states. fetch_next_timer_interrupt_remote() and tmigr_handle_remote() walk the migration hierarchy to find and expire timers belonging to CPUs that are idle. The defect is a time-of-check/time-of-use style race: run_timer_base(BASE_GLOBAL) processes a CPU's global timers, but jiffies can tick forward before tmigr_handle_remote() re-evaluates expiry, so a timer that becomes expired in that window is wrongly assumed already handled because cpu == smp_processor_id(). No CWE was assigned by the CNA, but the behavior maps to an infinite-loop / improper-synchronization class (loop with unreachable exit condition, CWE-835-like). The fix calls timer_expire_remote() unconditionally, relying on __run_timer_base() to cheaply return when the local wheel has nothing to expire.

RemediationAI

Vendor-released patch: update to a fixed stable kernel - 6.12.94, 6.18.36, 7.0.13, or 7.1 (or later) depending on your branch - which makes tmigr_handle_remote_cpu() call timer_expire_remote() unconditionally. Apply your distribution's corresponding kernel update once it ships these stable commits (07b3b83587fb, 1d6c2062b77b, d338e61ea940, d486b4934a8e). Because the upstream fix is the proper remedy and the bug is an internal timer-migration race with no configuration toggle that cleanly disables it, the only reliable mitigation short of patching is to reduce exposure to the migration path: disabling deep CPU idle / NO_HZ_FULL-style behavior or pinning the system out of states that exercise remote timer handling can lower the chance of the race, but at a real cost to power efficiency and idle latency, so patching is strongly preferred over any such workaround. Track fixes via the kernel.org stable commits above and the NVD page https://nvd.nist.gov/vuln/detail/CVE-2026-53180.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-53180 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy