Cloudanix VulnDB

CVE-2025-68214

Medium · 4.7

CVSS

4.7

EPSS

0.1%

Published

Dec 16, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in how the operating system manages scheduled tasks can cause errors or instability on affected computers.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in timer_shutdown_sync() clears the timer function pointer to NULL while the timer remains running on another CPU, leaving a pending timer with a NULL function that triggers WARN_ON_ONCE(!fn) on subsequent expiration.

Why it matters to the business

May produce kernel warnings or instability affecting system availability in Linux environments; low exploit likelihood and absence from known campaigns limit immediate operational disruption but still necessitates patching across kernel deployments and dependent packages.

How an attack unfolds

An attacker with local access arranges concurrent timer operations so that timer_shutdown_sync() executes while a timer is expiring on another CPU, resulting in a pending timer whose function has been cleared to NULL.

How to fix it

Upgrade the Linux kernel to version 6.1.159 or later; update affected packages such as ruby3.2-rails-8.0 and ruby3.2-rails-8.0-compat to 8.0.1-r2; apply the commit ba43ac025c4318241f8edf94f31d2eebab86991b in stable trees.

How to confirm the fix worked

Confirm running kernel version meets or exceeds the fixed release; review kernel logs for absence of the timer function NULL warning; inspect source for the corrected detach logic that only clears the function when detaching.

Typical attack path

  1. Obtain local user access on an affected Linux system
  2. Trigger or schedule timers in a manner that overlaps with shutdown operations across CPUs
  3. Force the race to leave a pending timer with NULL function pointer
  4. Observe resulting WARN_ON in expire_timers on next softirq

How to detect it

Search kernel logs for WARN_ON_ONCE(!fn) messages originating from expire_timers; look for unexpected timer detach behavior or softirq activity coinciding with shutdown calls.

What your security team should do

  • Apply kernel and package updates according to the listed fixed versions as soon as practical
  • Monitor kernel logs for timer-related WARN_ON messages as an indicator of exposure
  • Review systems with high timer activity for stability after patching

The record

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.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 0 6.1.159
Mageia:9 kernel 0 6.6.120-1.mga9
Mageia:9 kernel-linus 0 6.6.120-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.14-14.mga9
Mageia:9 kmod-xtables-addons 0 3.24-88.mga9

Related vulnerabilities