Cloudanix VulnDB

CVE-2026-98286

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's network monitoring code can cause the system to crash when stopping the monitor under heavy load.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel drop_monitor due to timer re-arming after timer_delete_sync() during teardown under memory pressure, leaving active timer in wheel when module unloads.

Why it matters to the business

Kernel panic or system instability during network monitoring teardown under load, leading to crashes and potential denial of service on affected Linux systems.

How an attack unfolds

An attacker with sufficient privileges triggers drop_monitor start/stop paths concurrently with memory allocation failures in reset functions, causing mod_timer re-arm after deletion; subsequent module unload executes timer callback in freed memory.

How to fix it

Update Linux kernel to version incorporating timer_shutdown_sync() in net_dm_trace_off_set, net_dm_hw_monitor_stop, and error paths; rebuild and deploy updated kernel images.

How to confirm the fix worked

Confirm presence of timer_shutdown_sync calls in drop_monitor teardown code paths via source inspection or kernel binary diff; test monitoring start/stop under memory pressure to ensure no re-arming occurs.

Typical attack path

  1. Start drop_monitor tracing or hardware monitoring
  2. Trigger concurrent dm_alert_work execution under memory pressure
  3. Cause allocation failure in reset_per_cpu_data to re-arm send_timer
  4. Execute timer_delete_sync followed by cancel_work_sync
  5. Unload module while timer remains active in wheel
  6. Timer fires executing sched_send_work on freed memory

How to detect it

Review kernel logs for use-after-free or timer-related panics during drop_monitor teardown; inspect module unload sequences coinciding with active send_timer events.

What your security team should do

  • Prioritize kernel updates on systems using drop_monitor for network diagnostics
  • Monitor for kernel oops or panic logs related to timer callbacks post-module unload
  • Restrict unprivileged access to net_dm interfaces until patched

The record

In the Linux kernel, the following vulnerability has been resolved: drop_monitor: use timer_shutdown_sync() to prevent timer rearming during teardown In drop_monitor teardown paths (net_dm_trace_off_set(), net_dm_hw_monitor_stop(), and error unwind paths in net_dm_trace_on_set() and net_dm_hw_monitor_start()), per-CPU timers are stopped using timer_delete_sync() followed by cancel_work_sync(). However, there is a circular dependency between send_timer and dm_alert_work: 1) sched_send_work() (timer callback) schedules dm_alert_work. 2) send_dm_alert() / net_dm_hw_summary_work() calls reset_per_cpu_data() or net_dm_hw_reset_per_cpu_data(). 3) If memory allocation fails under memory pressure in the reset function, it re-arms the timer via mod_timer(&data->send_timer, ...). If dm_alert_work is running concurrently while timer_delete_sync() executes on another CPU, an allocation failure in the worker will re-arm the timer after timer_delete_sync() has already returned. Once cancel_work_sync() completes and module_put() is called, the timer remains active in the timer wheel. If the module is then unloaded, the timer will fire and execute sched_send_work() in freed memory, triggering a kernel panic / use-after-free. Switch from timer_delete_sync() to timer_shutdown_sync(). This guarantees that any in-flight timer handler has finished and prevents subsequent re-arming attempts from running workers from succeeding. When monitoring is restarted later, timer_setup() is invoked, which cleanly re-initializes the timer.

Affected packages

Ecosystem Package Introduced Fixed