CVE-2025-39987 in Linux
Sumário
de VulDB • 24/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
can: hi311x: preencher ndo_change_mtu() para evitar estouro de buffer
O envio de um pacote PF_PACKET permite contornar a lógica do framework CAN e alcançar diretamente a função xmit() de um driver CAN. A única verificação realizada pelo framework PF_PACKET é garantir que o tamanho de skb->len se encaixe no MTU da interface.
Infelizmente, como o driver sun4i_can não preenche seu net_device_ops->ndo_change_mtu(), é possível para um atacante configurar um MTU inválido, por exemplo, executando:
$ ip link set can0 mtu 9999
Após isso, o atacante poderia abrir um soquete PF_PACKET usando o protocolo ETH_P_CANXL:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
para injetar quadros CAN XL maliciosos. Por exemplo:
struct canxl_frame frame = {
.flags = 0xff, .len = 2048, };
As funções xmit() dos drivers CAN chamam can_dev_dropped_skb() para verificar se o skb é válido. Infelizmente, nas condições acima, o pacote malicioso consegue passar pelas verificações de can_dev_dropped_skb():
1. o skb->protocol está definido como ETH_P_CANXL, o que é válido (a função não verifica as capacidades reais do dispositivo).
2. o comprimento é um comprimento válido para CAN XL.
Assim, hi3110_hard_start_xmit() recebe um quadro CAN XL que não consegue manipular corretamente, interpretando-o erroneamente como um quadro CAN. O driver consumirá frame->len diretamente, sem verificações adicionais.
Isso pode resultar em um estouro de buffer posteriormente em hi3110_hw_tx() na seguinte linha:
memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len);
Aqui, frame->len corresponde ao campo flags do quadro CAN XL. No nosso exemplo anterior, definimos canxl_frame->flags como 0xff. Como o comprimento máximo esperado é 8, ocorre um estouro de buffer de 247 bytes!
Preencher net_device_ops->ndo_change_mtu() garante que o MTU da interface não possa ser definido como um valor maior que CAN_MTU. Ao corrigir a causa raiz, isso previne o estouro de buffer.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.