LiveActive security incident?Get immediate response
CVE Record

CVE-2025-21816: hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING

In the Linux kernel, the following vulnerability has been resolved: hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING hrtimers are migrated away from the dying CPU to any online target at the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers handling tasks involved in the CPU hotplug forward progress. However wakeups can still be performed by the outgoing CPU after CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal ball power management based election, earliest timer already enqueued, timer migration enabled or not), the target may eventually be the current CPU even if offline. If that happens, the timer is eventually ignored. The most notable example is RCU which had to deal with each and every of those wake-ups by deferring them to an online CPU, along with related workarounds: _ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying) _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq) The problem isn't confined to RCU though as the stop machine kthread (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end of its work through cpu_stop_signal_done() and performs a wake up that eventually arms the deadline server timer: WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: <TASK> start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread Instead of providing yet another bandaid to work around the situation, fix it in the hrtimers infrastructure instead: always migrate away a timer to an online target whenever it is enqueued from an offline CPU. This will also allow to revert all the above RCU disgraceful hacks.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue can leave high-resolution timers queued on a CPU that is going offline, causing the timer to be ignored. The sources describe reliability and scheduling impact during CPU hotplug activity, not a confirmed remote attack path.

Executive priority

Treat as a kernel reliability issue requiring normal patch governance unless vendor guidance elevates severity for your environment. It is not shown as actively exploited in the provided sources, but kernel defects can affect high-value infrastructure stability.

Technical view

The flaw is in hrtimer migration after CPUHP_AP_HRTIMERS_DYING. Wakeups from a dying CPU can arm bandwidth or deadline timers back onto an offline CPU. The upstream fix forces timers enqueued from offline CPUs onto an online target.

Likely exposure

Exposure is limited to Linux kernels carrying this hrtimer CPU hotplug behavior. Systems using CPU offlining, hotplug, RCU nocb, real-time scheduling, or scheduler bandwidth timers may be more relevant. Distro package status must be confirmed from vendor advisories.

Exploitation context

The bundle does not show KEV listing, active exploitation, exploit availability, CVSS, or CWE data. The described trigger is internal kernel CPU hotplug and wakeup behavior, so business urgency depends on kernel versions and operational use of CPU hotplug paths.

Researcher notes

The key behavior is timer enqueue after CPUHP_AP_HRTIMERS_DYING choosing the outgoing offline CPU. The fix is infrastructure-level migration to an online CPU, replacing subsystem-specific RCU workarounds. Exact affected ranges need vendor or upstream branch interpretation.

Mitigation direction

  • Update affected Linux kernels using vendor-supported packages or stable kernel fixes.
  • Review Debian LTS and other distro advisories for backported kernel package versions.
  • Prioritize hosts that use CPU hotplug, isolation, real-time workloads, or aggressive power management.
  • Check vendor guidance before applying manual kernel patches.

Validation and detection

  • Inventory running kernel versions across Linux fleets.
  • Map each kernel to vendor advisories or referenced stable commits.
  • Review kernel logs for hrtimer warnings during CPU hotplug events.
  • Confirm updated hosts run a kernel package containing the hrtimer migration fix.
Prepared
Confidence
medium
Sources
8

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2025-21816 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
1ADP providers
7Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CVECVE Program Container

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux75b5016ce325f1ef9c63e5398a1064cf8a7a7354, 53f408cad05bb987af860af22f4151e5a18e6ee8, 5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94, 5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94, 5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94, 9a2fc41acb69dd4e2a58d0c04346c3333c2341fc, 54d0d83a53508d687fd4a225f8aa1f18559562d0, 7f4c89400d2997939f6971c7981cc780a219e36b, 6fcbcc6c8e52650749692c7613cbe71bf601670d, 6.1.68, 6.6.7, 4.19.302, 5.4.264, 5.10.204, 5.15.143unaffected
LinuxLinux6.7, 0, 6.1.141, 6.6.93, 6.12.14, 6.13.3, 6.14affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.