Strobes VIStrobes VI
CVE DatabaseThreat ActorsResearchAdvisoryAPI Docs
Visit Strobes.coSign Up for Strobes
CVE DatabaseThreat ActorsResearchAdvisoryAPI Docs
Tools
KB Lookup
Visit Strobes.coSign Up for Strobes
HomeCVEs

Do you like the insights?

Strobes vulnerability intelligence is a key component of their Exposure Management platform that helps organizations understand, prioritize, and address security vulnerabilities more effectively.

© 2026 Strobes Security. All rights reserved.
HomeCVEsCVE-2025-68214

CVE-2025-68214

Published: February 3, 2026
Last updated:17 hours ago (February 3, 2026)
Exploit: NoZero-day: NoPatch: YesTrend: Neutral
TL;DR
Updated February 3, 2026

CVE-2025-68214 is a low severity vulnerability with a CVSS score of 0.0. No known exploits currently, and patches are available.

Key Points
  • 1Low severity (CVSS 0.0/10)
  • 2No known public exploits
  • 3Vendor patches are available
Severity Scores
CVSS v30.0
CVSS v20.0
Priority Score0.0
EPSS Score0.0
None
Exploitation LikelihoodMinimal
0.00%EPSS

Very low probability of exploitation

Monitor and patch as resources allow
0.00%
EPSS
0.0
CVSS
No
Exploit
Yes
Patch
Low Priority
no major risk factors

EPSS predicts the probability of exploitation in the next 30 days based on real-world threat data, complementing CVSS severity scores with actual risk assessment.

Description

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.

CVSS v3 Breakdown
Attack Vector:-
Attack Complexity:-
Privileges Required:-
User Interaction:-
Scope:-
Confidentiality:-
Integrity:-
Availability:-
Trend Analysis
Neutral
Advisories
GitHub AdvisoryNVD
Cite This Page
APA Format
Strobes VI. (2026). CVE-2025-68214 - CVE Details and Analysis. Strobes VI. Retrieved February 3, 2026, from https://vi.strobes.co/cve/CVE-2025-68214
Quick copy link + title

Please cite this page when referencing data from Strobes VI. Proper attribution helps support our vulnerability intelligence research.