PT-2026-106615 · Linux · Linux

CVE-2026-98286

·

Published

2026-10-06

·

Updated

2026-10-06

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-98286

Affected Products

Linux