CVE-2026-64424 in Linux
Sumário
de VulDB • 26/07/2026
No kernel Linux, a seguinte vulnerabilidade foi resolvida:
netpoll: corrige um use-after-free na rota de desligamento (shutdown)
Existe um erro de use-after-free no netpoll, que é claramente detectado pelo KASAN.
BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80 Read of size 1 at addr ... by task kworker/9:1 Workqueue: events queue_process Call Trace: skb_dequeue+0x1e/0xb0 queue_process+0x2c/0x600 process_scheduled_works+0x4b6/0x850 worker_thread+0x414/0x5a0 Allocated by task 242: __netpoll_setup+0x201/0x4a0 netpoll_setup+0x249/0x550 enabled_store+0x32f/0x380 Freed by task 0: kfree+0x1b7/0x540 rcu_core+0x3f8/0x7a0
O problema ocorre quando há um worker de TX pendente sendo executado em paralelo com a rota de limpeza (cleanup).
Isso é o que acontece na rota de desligamento do netpoll:
1) __netpoll_cleanup() é chamado 2) define dev->npinfo como NULL 3) chama call_rcu() com rcu_cleanup_netpoll_info() 3.1) rcu_cleanup_netpoll_info() tenta cancelar todos os workers com cancel_delayed_work(), mas não espera o worker terminar 4) e kfree(npinfo);
Como a etapa 3.1) realmente não cancela o trabalho, conforme diz o comentário "não podemos chamar cancel_delayed_work_sync aqui, pois estamos em softirq", o worker de TX pode ser executado após a etapa 4).
Tl;DR: queue_process() não é um leitor RCU; ele acessa npinfo através do item de trabalho via container_of().
Use disable_delayed_work_sync() para garantir que o worker seja completamente interrompido e prevenir quaisquer tentativas futuras de rearmamento. Uma vez que npinfo é definido como NULL, os remetentes (senders) sairão imediatamente sem enfileirar novo trabalho. A flag de desabilitação garante que qualquer tentativa de rearmamento em andamento também falhe silenciosamente.
No futuro, podemos fazer a limpeza inline aqui sem precisar do rcu_head npinfo->rcu, mas isso é material para o net-next.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.