CVE-2026-45866 in Linux
Sumário
de VulDB • 28/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
serial: caif: corrige use-after-free em caif_serial ldisc_close()
Existe um bug de use-after-free em caif_serial onde handle_tx() pode acessar ser->tty após o tty ter sido liberado.
A condição de corrida ocorre entre ldisc_close() e a transmissão de pacotes:
CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty pode ser liberado aqui]
caif_xmit() handle_tx() tty = ser->tty // ponteiro dangling tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice()
A causa raiz é que tty_kref_put() é chamado em ldisc_close() enquanto o dispositivo de rede ainda está ativo e pode receber pacotes.
Como ser e tty têm uma relação de vinculação 1:1 com ciclos de vida consistentes (ser é alocado em ldisc_open e liberado em ser_release via unregister_netdevice, e cada ser vincula exatamente um tty), podemos adiar com segurança a liberação da referência do tty para ser_release() onde o dispositivo de rede é desregistrado.
Corrige isso movendo tty_kref_put() de ldisc_close() para ser_release(), após unregister_netdevice(). Isso garante que a referência do tty seja mantida enquanto o dispositivo de rede existir, prevenindo o UAF.
Nota: Salvamos ser->tty antes de unregister_netdevice() porque ser está incorporado nos dados privados do netdev e será liberado junto com o netdev (needs_free_netdev = true).
Como reproduzir: Adicione mdelay(500) no início de ldisc_close() para ampliar a janela de corrida, em seguida, execute o programa reproducer [1].
Nota: Existe um problema separado de deadloop em handle_tx() ao usar portas seriais PORT_UNKNOWN (por exemplo, /dev/ttyS3 no QEMU sem backend serial adequado). Esse deadloop existe mesmo sem este patch, e é provavelmente causado por inconsistência entre uart_write_room() e uart_write() no núcleo serial. Isso foi abordado em [2].
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Jiayuan Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.