CVE-2026-99033 in Linuxinformação

Sumário

de VulDB • 23/10/2026

No kernel do Linux, a seguinte vulnerabilidade foi resolvida:

net/packet: proteger o empurrão (push) do cabeçalho da camada de enlace em packet_rcv_spkt()

packet_rcv_spkt() restaura o cabeçalho da camada de enlace com:

skb_push(skb, skb->data - skb_mac_header(skb));

Essa subtração só é significativa quando o dispositivo possui realmente um cabeçalho na camada de enlace. Tanto packet_rcv() quanto tpacket_rcv() envolvem essa operação em dev_has_header(), que também é a condição descrita no comentário do bloco no topo do arquivo para a restauração; packet_rcv_spkt() não faz isso. O commit d549699048b4 ("net/packet: fixar recebimento de pacotes em dispositivos L3 sem cabeçalho duro visível") introduziu o auxiliar e alterou os dois locais de chamada, mas este ficou para trás.

Um dispositivo sem um cabeçalho ll (camada de enlace) visível pode deixar skb->mac_header no sentinel 0xFFFF, que é como __alloc_skb() o inicializa. Um CAN skb faz isso: init_can_skb() define pkt_type e ip_summed, mas não redefine os cabeçalhos, e o commit 9f10374bb024 ("can: remover infraestrutura privada de espaço reservado (headroom) do CAN") removeu as chamadas skb_reset_*_header() que antes estavam presentes. Então, skb_mac_header() é 0xFFFF, o comprimento torna-se um número negativo grande e skb_push() relata isso através de skb_under_panic() -- a partir do contexto softirq, portanto, resulta em uma falha completa no sistema (panic) mesmo com panic_on_oops=0:

skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x50/0x60 Call Trace: <IRQ> skb_push+0x38/0x40 packet_rcv_spkt+0xe1/0x170 __netif_receive_skb_core.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt

O tipo de soquete é acessível: packet_create() aceita SOCK_PACKET junto com SOCK_RAW e SOCK_DGRAM sob a mesma verificação CAP_NET_RAW, e nem o comprimento do soquete nem uma verificação de capacidade impedem que ele alcance uma interface CAN.

As chamadas skb_reset_*_header() ausentes em init_can_skb() são por si só um regresso (regression) e estão sendo corrigidas separadamente, mas um socket packet não deve transformar uma camada de enlace que não inicializou seu cabeçalho mac em uma falha no kernel (kernel panic). Proteja o empurrão da mesma forma que os outros dois caminhos de recebimento fazem.

Testado na v7.3-rc5 sob QEMU com um dispositivo slcan em um pty, que é o caminho RX do driver: can0 não reproduz o problema porque can_send() redefine os cabeçalhos ao sair. Um único socket SOCK_PACKET vinculado a can0 e uma única frame escrita na disciplina da linha causam panic no kernel sem patch com o trace acima; a mesma imagem com este patch não exibe panic e desliga normalmente. Ambos os kernels são desta árvore, defconfig mais CONFIG_CAN_SLCAN=y, diferindo apenas neste hunk.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Responsável

Linux

Reservar

25/09/2026

Divulgação

23/10/2026

Moderação

aceite

Entrada

VDB-425837

EPSS

0.00000

KEV

não

Atividades

muito baixo

Fontes

Might our Artificial Intelligence support you?

Check our Alexa App!