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

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

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

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
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. …

Unlock full vulnerability intelligence

  • Risk assessment & exploitation conditions
  • Attack chain visualization
  • Remediation with exact patch versions
  • Threat intelligence from 22 sources
  • Personal watchlist & email alerts

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Access
Run workload scheduling global timers
Delivery
CPU goes idle, remote timer handling engages
Exploit
jiffies advance during the check window
Execution
expired timer skipped and re-queued as now
Persist
goto-again loop spins indefinitely
Impact
affected CPU livelocks (DoS)

Vulnerability AssessmentAI

Exploitation Triggering requires the kernel's hierarchical timer migration to be in use (idle CPUs offloading other CPUs' global timers) and a precise timing window where jiffies advance after run_timer_base(BASE_GLOBAL) processes a CPU's global timers but before tmigr_handle_remote() re-evaluates expiry, causing a timer to become expired in the remote-handling phase for the CPU where cpu == smp_processor_id(). … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment The signals point to a genuine but low-likelihood reliability bug rather than a security priority. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario On an affected kernel, a system running workloads that schedule global timers while CPUs go idle hits the jiffies-advance race during remote timer handling; the affected CPU enters the goto-again livelock, an expired timer's callback is never invoked, and the CPU spins indefinitely, degrading or hanging the host. There is no public exploit identified at time of analysis, and the condition is more likely to manifest as a spontaneous reliability failure than as a deliberately weaponized attack.
Remediation 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. … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

24 hours: Identify Linux systems in your environment and determine exposure to the timer subsystem vulnerability. …

Sign in for detailed remediation steps and compensating controls.

Threat intelligence, references, and detailed analysis are available after sign-in.

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