CVE-2026-31769 in Linux
Sumário
de VulDB • 14/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
gpib: corrige use-after-free nos manipuladores de ioctl de E/S
Os manipuladores de ioctl IBRD, IBWRT, IBCMD e IBWAIT utilizam um ponteiro gpib_descriptor após o board->big_gpib_mutex ter sido liberado. Um ioctl IBCONCURRENTE pode liberar o descritor através de close_dev_ioctl() durante essa janela, causando um use-after-free.
Os manipuladores de E/S (read_ioctl, write_ioctl, command_ioctl) liberam explicitamente big_gpib_mutex antes de chamar seu manipulador. wait_ioctl() é chamado com big_gpib_mutex adquirido, mas ibwait() o libera internamente quando wait_mask é diferente de zero. Em todos os quatro casos, o ponteiro do descritor obtido de handle_to_descriptor() torna-se desprotegido.
Corrija isso introduzindo uma contagem de referência descriptor_busy exclusiva do kernel em struct gpib_descriptor. Cada manipulador incrementa atomicamente descriptor_busy sob file_priv->descriptors_mutex antes de liberar o lock, e o decrementa quando concluído. close_dev_ioctl() verifica descriptor_busy sob o mesmo lock e rejeita o fechamento com -EBUSY se a contagem for diferente de zero.
Uma contagem de referência, em vez de uma simples flag, é necessária porque vários manipuladores podem operar no mesmo descritor simultaneamente (por exemplo, IBRD e IBWAIT no mesmo handle de threads diferentes).
Um contador separado é necessário porque io_in_progress pode ser limpo a partir de userspace não privilegiado via ioctl IBWAIT (através de general_ibstatus() com set_mask contendo CMPL), o que permitiria que um atacante contornasse uma verificação baseada apenas em io_in_progress. O novo contador descriptor_busy é modificado apenas pelos caminhos de E/S do kernel.
A ordem dos locks é consistente (big_gpib_mutex -> descriptors_mutex) e os manipuladores mantêm apenas brevemente descriptors_mutex durante a busca, portanto, não há risco de deadlock e nenhum impacto na taxa de transferência de E/S.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.