CVE-2026-53180High· 7.5▾ TwilightIn 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 sof…
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Aug 2.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.3%
0.3% → 0.5%
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 ]
linux_kernel >= 6.9, < 6.12.94linux_kernel >= 6.13, < 6.18.36linux_kernel >= 6.19, < 7.0.13linux_kernel = 7.1Upgrade past the affected range:
linux_kernel 7.0.13Connected by shared product, vendor, weakness, or advisory.
CVE-2022-49742Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: f2fs: initialize locks earlier in f2fs_fill_super() syzbot is reporting lockdep warning at f2fs_handle_error() [1], for spin_lock(&sbi->error_lock) is called before sp…
CVE-2022-3303Medium· 4.7A race condition flaw was found in the Linux kernel sound subsystem due to improper locking
CVE-2022-2959High· 7.0A race condition was found in the Linux kernel's watch queue due to a missing lock in pipe_resize_ring()
CVE-2022-3028High· 7.0A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously
CVE-2025-71309Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix deadlock in ni_read_folio_cmpr Syzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr). This is caused by a lock inversion deadlock invo…
CVE-2025-21807Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: block: fix queue freeze vs limits lock order in sysfs store methods queue_attr_store() always freezes a device queue before calling the attribute store operation