CVE-2026-98286: drop_monitor: use timer_shutdown_sync() to prevent timer rearming during teardown

In the Linux kernel, the following vulnerability has been resolved:

dropmonitor: use timershutdownsync() to prevent timer rearming during teardown

In dropmonitor teardown paths (netdmtraceoffset(), netdmhwmonitorstop(), and error unwind paths in netdmtraceonset() and netdmhwmonitorstart()), per-CPU timers are stopped using timerdeletesync() followed by cancelworksync().

However, there is a circular dependency between sendtimer and dmalertwork: 1) schedsendwork() (timer callback) schedules dmalertwork. 2) senddmalert() / netdmhwsummarywork() calls resetpercpudata() or netdmhwresetpercpudata(). 3) If memory allocation fails under memory pressure in the reset function, it re-arms the timer via modtimer(&data->sendtimer, ...).

If dmalertwork is running concurrently while timerdeletesync() executes on another CPU, an allocation failure in the worker will re-arm the timer after timerdeletesync() has already returned. Once cancelworksync() completes and moduleput() is called, the timer remains active in the timer wheel. If the module is then unloaded, the timer will fire and execute schedsendwork() in freed memory, triggering a kernel panic / use-after-free.

Switch from timerdeletesync() to timershutdownsync(). 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, timersetup() is invoked, which cleanly re-initializes the timer.