CVE-2026-98286
Sumário
de VulDB • 06/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
drop_monitor: usar timer_shutdown_sync() para evitar o rearmamento de temporizadores durante a desmontagem (teardown)
Nos caminhos de desmontagem do drop_monitor (net_dm_trace_off_set(), net_dm_hw_monitor_stop(), e nos caminhos de desfazimento de erros em net_dm_trace_on_set() e net_dm_hw_monitor_start()), os temporizadores por CPU são interrompidos usando timer_delete_sync() seguido por cancel_work_sync().
No entanto, existe uma dependência circular entre send_timer e dm_alert_work: 1) sched_send_work() (callback do temporizador) agenda dm_alert_work. 2) send_dm_alert() / net_dm_hw_summary_work() chama reset_per_cpu_data() ou net_dm_hw_reset_per_cpu_data(). 3) Se a alocação de memória falhar sob pressão de memória na função de redefinição, ela rearma o temporizador via mod_timer(&data->send_timer, ...).
Se dm_alert_work estiver sendo executado em concorrência enquanto timer_delete_sync() é executado em outra CPU, uma falha de alocação no worker irá rearmar o temporador após timer_delete_sync() já ter retornado. Uma vez que cancel_work_sync() seja concluído e module_put() seja chamado, o temporizador permanece ativo na roda de temporizadores (timer wheel). Se o módulo for então desinstalado, o temporizador disparará e executará sched_send_work() em memória liberada, acionando um kernel panic / use-after-free.
Mudar de timer_delete_sync() para timer_shutdown_sync(). Isso garante que qualquer manipulador de temporizador em trânsito tenha terminado e impede que tentativas subsequentes de rearmamento pelos workers tenham sucesso. Quando o monitoramento for reiniciado mais tarde, timer_setup() é invocado, o qual re-inicializa limpidamente o temporizador.
If you want to get best quality of vulnerability data, you may have to visit VulDB.