CVE-2026-99033 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net/packet: proteggere l'operazione di push dell'intestazione del livello link (ll header) in packet_rcv_spkt()
packet_rcv_spkt() ripristina l'intestazione del livello link con:
skb_push(skb, skb->data - skb_mac_header(skb));
Questa sottrazione ha senso solo quando il dispositivo dispone effettivamente di un'intestazione a livello di collegamento. Sia packet_rcv() che tpacket_rcv() la avvolgono in dev_has_header(), che è anche la condizione espressa nel commento del blocco all'inizio del file per descrivere il ripristino; packet_rcv_spkt() non lo fa. Il commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header") ha introdotto l'helper e modificato i due punti di chiamata, ma questo è rimasto indietro.
Un dispositivo senza un'intestazione ll visibile può lasciare skb->mac_header al sentinella 0xFFFF a cui __alloc_skb() lo inizializza. Un CAN skb fa così: init_can_skb() imposta pkt_type e ip_summed ma non resetta le intestazioni, e il commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") ha rimosso le chiamate skb_reset_*_header() che erano presenti in precedenza.skb_mac_header() risulta quindi essere 0xFFFF, la lunghezza diventa un numero negativo molto grande e skb_push() lo segnala tramite skb_under_panic(), dal contesto softirq, causando così un panic completo del sistema anche con 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
Il tipo di socket è raggiungibile: packet_create() accetta SOCK_PACKET insieme a SOCK_RAW e SOCK_DGRAM dietro lo stesso controllo CAP_NET_RAW, né la lunghezza del socket né un controllo delle capacità impediscono l'accesso a un'interfaccia CAN.
Le chiamate skb_reset_*_header() mancanti in init_can_skb() costituiscono di per sé una regressione e vengono risolte separatamente, ma un socket packet non dovrebbe trasformare un livello di collegamento che non ha inizializzato la sua intestazione mac in un kernel panic. Proteggere l'operazione push come fanno gli altri due percorsi di ricezione.
Testato su v7.3-rc5 sotto QEMU con un dispositivo slcan su una pty, che è il percorso RX del driver: vcan non riproduce il problema perché can_send() resetta le intestazioni in uscita. Un socket SOCK_PACKET legato a can0 e un frame scritto nella disciplina della linea causano un panic nel kernel senza patch con la traccia sopra; la stessa immagine con questa patch non stampa alcun panic e si spegne normalmente. Entrambi i kernel appartengono a questo albero, defconfig più CONFIG_CAN_SLCAN=y, differendo solo in questo hunk.
Once again VulDB remains the best source for vulnerability data.