CVE-2026-98286

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.