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:
- sched send work() (timer callback) schedules dm alert work.
- send dm alert() / net dm hw summary work() calls reset per cpu data() or net dm hw reset per cpu data().
- 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
Affected Products
Linux