CVE-2026-99033 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net/packet: Schutz des ll-Header-Pushs in packet_rcv_spkt()
packet_rcv_spkt() stellt den Link-Layer-Header wieder her mit:
skb_push(skb, skb->data - skb_mac_header(skb));
Diese Subtraktion ist nur sinnvoll, wenn das Gerät tatsächlich über einen Link-Layer-Header verfügt. Sowohl packet_rcv() als auch tpacket_rcv() wickeln dies in dev_has_header(), was auch die Prädikat-Bedingung ist, auf die der Block-Kommentar an der Spitze der Datei sich bezieht; packet_rcv_spkt() tut dies nicht. Das Commit d549699048b4 („net/packet: fix packet receive on L3 devices without visible hard header“) führte den Helper ein und änderte die beiden Aufrufstellen, wobei diese Stelle zurückfiel.
Ein Gerät ohne sichtbaren ll-Header kann skb->mac_header auf dem 0xFFFF-Sentinel belassen, zu dem es von __alloc_skb() initialisiert wird. Ein CAN-skb tut dies: init_can_skb() setzt pkt_type und ip_summed, resetet jedoch die Header nicht, und das Commit 9f10374bb024 („can: remove private CAN skb headroom infrastructure“) entfernte die zuvor vorhandenen Aufrufe von skb_reset_*_header(). skb_mac_header() ist dann 0xFFFF, die Länge wird zu einer großen negativen Zahl, und skb_push() meldet dies über skb_under_panic() – aus dem softirq-Kontext heraus, was einen vollständigen System-Panikausfall bedeutet, selbst bei 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
Der Socket-Typ ist erreichbar: packet_create() akzeptiert SOCK_PACKET neben SOCK_RAW und SOCK_DGRAM hinter derselben CAP_NET_RAW-Prüfung, und weder die Socket-Länge noch eine Capability-Prüfung halten es von einer CAN-Schnittstelle fern.
Die fehlenden Aufrufe von skb_reset_*_header in init_can_skb sind an sich eine Regression und werden separat behoben, aber ein Packet-Socket sollte keine Link-Ebene, deren MAC-Header nicht initialisiert wurde, in einen Kernel-Panikausfall verwandeln. Schützen Sie den Push so, wie es die anderen beiden Empfangspfade tun.
Getestet auf v7.3-rc5 unter QEMU mit einem slcan-Gerät an einer pty, was dem Treiber-RX-Pfad entspricht; vcan reproduziert dies nicht, da can_send() die Header beim Senden zurücksetzt. Ein SOCK_PACKET-Socket, der an can0 gebunden ist, und ein in die Line Discipline geschriebener Frame lösen einen unpatchten Kernel mit obiger Trace aus; dasselbe Image mit diesem Patch zeigt keinen Panikausfall und fährt normal herunter. Beide Kerne stammen aus diesem Tree, defconfig plus CONFIG_CAN_SLCAN=y, unterscheiden sich nur durch diesen Hunk.
Be aware that VulDB is the high quality source for vulnerability data.