Linux Kernel
CVE-2025-68214
MEDIUM
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticated local access to multi-core host
-
ExploitDrive kernel path calling timer_shutdown_sync during expiry
-
ExecutionWin race leaving pending timer with NULL function
-
ImpactHit WARN_ON_ONCE in expire_timers (DoS)
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Concurrency control, locking
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires local, low-privileged code execution on an affected Linux kernel build (per CPE: 6.1.158 and 6.18-rc1 through rc6) running on an SMP/multi-core system, plus the ability to concurrently invoke a code path that calls timer_shutdown_sync() while the targeted timer is expiring on another CPU. Exploitation is strongly limited by an extremely narrow timing window (reflected as AC:H) that the attacker cannot deterministically force, by the need for existing local access (no remote vector - AV:L), and by impact being confined to a WARN_ON_ONCE kernel warning that only escalates to a crash when panic_on_warn is enabled. It is not remotely reachable and causes no data exposure. |
| Impact | This is a low-priority issue despite affecting an ubiquitous product. All signals align toward low real-world risk: the CVSS vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, base 4.7 MEDIUM) describes a local, high-complexity, authenticated flaw with no confidentiality or integrity impact and only an availability effect; EPSS is 0.13% (2nd percentile), among the lowest exploitation probabilities; there is no CISA KEV listing and no public exploit identified at time of analysis. The high attack complexity (AC:H) is well-justified because the flaw is a timing-dependent race (CWE-362) between timer_shutdown_sync() and timer expiration on a separate CPU, with a very narrow window an attacker cannot reliably force. No SSVC decision data was provided in the input. One notable inconsistency: the input Tags include 'Information Disclosure', but the CVSS vector explicitly sets C:N/I:N and A:H - the actual impact is availability (a WARN_ON kernel warning), not disclosure, so that tag appears mislabeled and should not drive prioritization. |
| Exploit ScenarioDerived | A local, low-privileged user on a multi-core host repeatedly drives a kernel code path that invokes timer_shutdown_sync() while the same timer is expiring on another CPU, hoping to win the narrow race so a pending timer is left with a NULL function pointer. The next timer expiry then hits the WARN_ON_ONCE(!fn) check in expire_timers(), producing a kernel warning (and a crash only if panic_on_warn is set). No public exploit code is known, and the high attack complexity makes reliable triggering difficult. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
A race condition in the Linux kernel timer subsystem allows timer_shutdown_sync() to NULL out a timer's callback function while that timer is still executing on another CPU, leaving a pending timer whose function pointer is NULL and triggering the WARN_ON_ONCE(!fn) check in expire_timers(). The issue affects local, low-privileged code on SMP systems running kernel 6.1.158 or 6.18-rc1 through rc6 that can concurrently invoke a timer-shutdown path during timer expiry, and its practical impact is confined to a kernel warning that only becomes a denial of service when panic_on_warn is enabled - there is no remote vector and no data exposure (independent assessment: CVSS 3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L). No public exploit code identified at time of analysis, EPSS is 0.13% (2nd percentile), and the upstream fix is available as stable-tree commits.
RemediationAI
The primary fix is to update to a kernel build containing the corrected timer_shutdown_sync() logic published in the Linux stable tree - the upstream commits 176725f4848376530a0f0da9023f956afcc33585, 1a975716cc8977f461e45e28e3e5977d46ad7a6a, 20739af07383e6eb1ec59dcd70b72ebfa9ac362c, 6665fbd7730b26d770c232b20d1b907e6a67a914, a01efa7a780c42ac5170a949bd95c9786ffcc60a and ba43ac025c4318241f8edf94f31d2eebab86991b (https://git.kernel.org/stable/c/<commit>) are visible in the NVD references, and patch status is 'patch available per vendor advisory', so consult your distribution's kernel advisory for the exact released version that carries the backport before scheduling a reboot. Note that the upstream refs are stable-branch commits rather than a single tagged release, so the exact fixed package version must be confirmed with the vendor or distro erratum rather than assumed. As a compensating control where immediate kernel update is not possible, disable panic_on_warn (sysctl kernel.panic_on_warn=0 or the boot parameter panic_on_warn=0) so that the benign WARN_ON_ONCE does not escalate into a full system panic; the trade-off is loss of the automatic crash-on-warning safety net and continued presence of noisy kernel warnings, and this only mitigates the denial-of-service escalation, not the underlying race. Reducing the number of concurrently running local workloads that drive timer shutdown paths lowers the odds of hitting the narrow timing window, but because the race is not deterministically controllable this is not a reliable mitigation and should be treated as temporary until the patched kernel is deployed.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw resides in the kernel's timer wheel implementation, specifically the timer_shutdown_sync() helper added to safely tear down timers without re-arming races. Under CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization), timer_shutdown_sync() takes the timer base lock, checks base->running_timer, and then unconditionally sets timer->function = NULL when a shutdown is requested - even when the timer it is asked to stop is currently executing in softirq context on another CPU. In the interleaving described in the patch, CPU1 has already set base->running_timer and entered call_timer_fn(), then re-arms the timer via mod_timer() and clears base->running_timer; CPU0 concurrently clears the function pointer, so the timer is left pending with a NULL callback and the next expiry hits WARN_ON_ONCE(!fn) in expire_timers(). The correction is to clear the callback only when the timer is actually detached (detach_if_pending), leaving the function pointer intact while the timer is running, since the running timer detaches itself cleanly on completion. Although the supplied tags include an 'Information Disclosure' label, the mechanism is a synchronization/WARN defect in softirq timer expiry - no memory unsafety such as read/write out of bounds or use-after-free is described, and no confidentiality impact is substantiated by the assessment (C:N). Affected CPE data covers cpe:2.3:o:linux:linux_kernel across unversioned branch ranges plus the explicit builds 6.1.158 and 6.18 release candidates rc1 through rc6.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Local-only timing race (AV:L/AC:H) reachable by a low-priv user (PR:L); impact is a WARN_ON splat, so A:L with no confidentiality or integrity effect.
Primary rating from NVD.
CVSS VectorNVD
DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
timers: Fix NULL function pointer race in timer_shutdown_sync()
There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers().
The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:
CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base()
The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers().
Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
GitHub PoC
Exploit-DB