CVE-2026-98286 in Linux
Riassunto
di VulDB • 06/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
drop_monitor: utilizzare timer_shutdown_sync() per prevenire il riarmamento del timer durante le operazioni di teardown (smontaggio)
Nei percorsi di teardown di drop_monitor (net_dm_trace_off_set(), net_dm_hw_monitor_stop(), e nei percorsi di rollback degli errori in net_dm_trace_on_set() e net_dm_hw_monitor_start()), i timer per-CPU vengono arrestati utilizzando timer_delete_sync() seguito da cancel_work_sync().
Tuttavia, esiste una dipendenza circolare tra send_timer e dm_alert_work: 1) sched_send_work() (callback del timer) pianifica l'esecuzione di dm_alert_work. 2) send_dm_alert() / net_dm_hw_summary_work() chiama reset_per_cpu_data() o net_dm_hw_reset_per_cpu_data(). 3) Se si verifica un errore di allocazione della memoria sotto pressione nella funzione di reset, il timer viene riarmato tramite mod_timer(&data->send_timer, ...).
Se dm_alert_work è in esecuzione contemporaneamente mentre timer_delete_sync() viene eseguito su un altro CPU, un errore di allocazione nel worker porterà al riarmamento del timer dopo che timer_delete_sync() ha già restituito il controllo. Una volta completata cancel_work_sync() e chiamata module_put(), il timer rimane attivo nella struttura dati dei timer (timer wheel). Se successivamente il modulo viene disinstallato, il timer scattará ed eseguirà sched_send_work() in memoria liberata, causando un kernel panic o un use-after-free.
Passare da timer_delete_sync() a timer_shutdown_sync(). Questo garantisce che qualsiasi handler del timer ancora in esecuzione sia terminato e impedisce ai tentativi di riarmamento successivi nei worker di avere successo. Quando il monitoraggio viene riavviato successivamente, viene invocata timer_setup(), la quale reinizializza correttamente il timer.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.