CVE-2026-98286 in Linux
Zusammenfassung
von VulDB • 06.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drop_monitor: Verwendung von timer_shutdown_sync(), um ein erneutes Scharfmachen des Timers während der Herunterfahrphase zu verhindern
In den drop_monitor-Herunterfahrrouten (net_dm_trace_off_set(), net_dm_hw_monitor_stop() sowie den Fehler-Rollback-Pfaden in net_dm_trace_on_set() und net_dm_hw_monitor_start()) werden pro-CPU-Timer mit timer_delete_sync() gefolgt von cancel_work_sync() gestoppt.
Es besteht jedoch eine zyklische Abhängigkeit zwischen send_timer und dm_alert_work: 1) sched_send_work() (Timer-Callback) plant dm_alert_work ein. 2) send_dm_alert() / net_dm_hw_summary_work() ruft reset_per_cpu_data() oder net_dm_hw_reset_per_cpu_data() auf. 3) Wenn im Reset-Funktion bei Speicherknappheit eine Speicherzuweisung fehlschlägt, wird der Timer über mod_timer(&data->send_timer, ...) erneut scharfgeschaltet.
Wenn dm_alert_work parallel zur Ausführung von timer_delete_sync() auf einer anderen CPU läuft, kann ein Zuweisungsfehler im Worker den Timer nach dem Rückgabewert von timer_delete_sync() erneut scharf schalten. Sobald cancel_work_sync() abgeschlossen ist und module_put() aufgerufen wird, bleibt der Timer aktiv im Timer-Rad (timer wheel). Wird das Modul anschließend entladen, feuert der Timer und führt sched_send_work() in freigegebenem Speicher aus, was einen Kernel-Panic / Use-After-Free auslöst.
Wechsel von timer_delete_sync() zu timer_shutdown_sync(). Dies garantiert, dass jeder gerade laufende Timer-Handler abgeschlossen ist und verhindert, dass nachfolgende Versuche zum erneuten Scharfmachen durch laufende Worker erfolgreich sind. Wenn die Überwachung später wieder gestartet wird, wird timer_setup() aufgerufen, was den Timer sauber neu initialisiert.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.