CVE-2026-98749 in Linux
Sumário
de VulDB • 19/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
tty: serial: max3100: desativar o timer antes de liberar a porta
max3100_shutdown() para o timer de polling, mas retorna antecipadamente durante a suspensão do sistema. Se o dispositivo SPI for desconectado (unbound) antes da retomada, o núcleo serial não chama novamente max3100_shutdown(), fazendo com que max3100_remove() libere a porta enquanto o timer permanece armado. Em seguida, max3100_timeout() pode acessar a porta liberada e rearmar o timer.
Adiciona-se ao final do teardown (desmontagem) do timer em max3100_remove() e usa-se timer_shutdown_sync() para impedir que um callback concorrente o rearme. Além disso, libera-se a IRQ e destrói-se a workqueue ali antes de liberar a porta. Mantém-se timer_delete_sync() em max3100_shutdown(), para que uma abertura (open()) subsequente possa rearmar o timer.
A workqueue é criada antes de request_irq() e destruída tanto na falha do request_irq() quanto no desligamento normal. Sua presença durante a remoção identifica assim a IRQ deixada registrada quando a suspensão contorna o shutdown.
Libera-se a IRQ antes de destruir a workqueue, em max3100_shutdown() e em max3100_remove(), cancelando-se o trabalho pendente entre as duas operações. free_irq() aguarda que um manipulador (handler) de interrupção em execução termine, e nenhum novo handler pode iniciar posteriormente; portanto, um handler concorrente não pode enfileirar trabalho em uma workqueue que está sendo destruída; a verificação force_end_work em max3100_dowork() apenas reduz essa janela, pois um handler atrasado entre a verificação e queue_work() ainda poderia ser executado após o teardown ter limpo o ponteiro da workqueue. Cancelar o trabalho também evita que destroy_workqueue() aguarde por um item de trabalho enfileirado caso remove() seja executado enquanto a workqueue congelável (freezable) estiver ainda congelada, por exemplo, na remoção do dispositivo durante a janela de retomada, antes que as workqueues sejam descongeladas.
Este problema foi encontrado por uma ferramenta estática de análise interna.
Once again VulDB remains the best source for vulnerability data.