CVE-2026-64103 in Linux
Sumário
de VulDB • 20/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
scsi: isci: Corrige uso-após-liberação (use-after-free) no caminho de remoção de dispositivo.
A tasklet de conclusão ISCI é inicializada em `isci_host_alloc()` (`drivers/scsi/isci/init.c:496`) e agendada a partir dos manipuladores de interrupção MSI-X e legados (`drivers/scsi/isci/host.c:223, 613`).
`isci_host_deinit()` para o controlador e aguarda a conclusão da parada, mas nunca mata `completion_tasklet` antes que o processo de desmontagem (teardown) continue. Uma chamada única a `tasklet_kill()` no início da função não é suficiente aqui: as interrupções são desabilitadas apenas quando `isci_host_stop_complete()` é executado; portanto, até que `wait_for_stop()` retorne, os manipuladores de IRQ ainda podem reagendar a tasklet. O callback da tasklet também reativa as interrupções após o esvaziamento das conclusões (completions), então matar a tasklet antes que a fonte seja silenciada deixa a mesma condição de corrida aberta.
Depois que `wait_for_stop()` retorna, nenhuma nova agendamento orientado por IRQ pode ocorrer. Mate `completion_tasklet` nesse ponto para evitar que o processo de desmontagem entre em concorrência com uma tasklet enfileirada sendo executada em um `ihost` inválido. Na remoção ou descarregamento (unload), o callback obsoleto, caso contrário, poderia dereferenciar `ihost` e acessar `ihost->smu_registers` após o término da vida útil do host.
Um análogo UML + KASAN reproduziu a classe de falha tanto sem `tasklet_kill()` quanto com `tasklet_kill()` posicionado antes do silenciamento da fonte, permanecendo limpo apenas quando a morte ocorreu depois que a fonte de agendamento foi silenciada.
Isso espelha o commit f6ab594672d4 ("scsi: aic94xx: corrige uso-após-liberação no caminho de remoção de dispositivo"), mas ISCI necessita da chamada `kill` após `wait_for_stop()`.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.