CVE-2026-99033
Beschrijving NL
In de Linux-kernel is de volgende kwetsbaarheid verholpen:
net/packet: bescherm de ll-header push in packet_rcv_spkt()
packet_rcv_spkt() herstelt de linklaagheader met
skb_push(skb, skb->gegevens - skb_mac_header(skb));
Die aftrekking is alleen zinvol als het apparaat daadwerkelijk een verbinding heeft.
laagkop. packet_rcv() en tpacket_rcv() wikkelen het beide in
dev_has_header(), wat ook het predicaat is van het blokcommentaar bij de
Bovenaan het bestand staat dat het herstelproces wordt beschreven in termen van; packet_rcv_spkt() doet
niet. commit d549699048b4 ("net/packet: fix packet receive on L3")
apparaten zonder zichtbare harde header") introduceerden de helper en veranderden
De twee locaties waar gebeld werd, bleven achter. Een apparaat zonder zichtbare ll-header kan skb->mac_header op de volgende manier laten staan:
0xFFFF sentinel die door __alloc_skb() wordt geïnitialiseerd. Een CAN skb doet het volgende:
init_can_skb() stelt pkt_type en ip_summed in, maar reset de niet.
headers, en commit 9f10374bb024 ("can: verwijder privé CAN skb")
"Headroom Infrastructure") liet de skb_reset_*_header()-aanroepen vallen die
was daar vroeger. skb_mac_header() is dan 0xFFFF, de lengte wordt
een groot negatief getal en skb_push() rapporteert dit via
skb_under_panic() -- vanuit softirq-context, dus het is een volledige systeempaniek
zelfs met panic_on_oops=0:
skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0
Kernelfout in net/core/skbuff.c:214! RIP: 0010:skb_panic+0x50/0x60
Oproeptracering:
skb_push+0x38/0x40
packet_rcv_spkt+0xe1/0x170
__netif_receive_skb_core.constprop.0+0x7e8/0xd30
... Kernelpaniek - synchronisatie mislukt: Fatale uitzondering bij onderbreking
Het sockettype is bereikbaar: packet_create() accepteert SOCK_PACKET
naast SOCK_RAW en SOCK_DGRAM achter dezelfde CAP_NET_RAW-controle,
en noch de lengte van de socket, noch een capaciteitscontrole houdt het tegen.
via een CAN-interface. De ontbrekende skb_reset_*_header() aanroepen in init_can_skb() zijn een
regressie in hun eigen recht en worden afzonderlijk vastgesteld, maar een
packet socket mag geen linklaag draaien die zijn
mac header in een kernel panic. Bewaak het duwtje op de manier waarop de andere twee
ontvangstpaden doen. Getest op v7.3-rc5 onder QEMU met een slcan-apparaat op een pty, dat
het RX-pad van de driver: vcan reproduceert het niet, omdat can_send()
reset de headers op weg naar buiten. Eén SOCK_PACKET-socket gebonden aan
kan0 en één frame geschreven in de regel discipline paniek een
Ongepatchte kernel met de bovenstaande foutmelding; dezelfde image met deze patch.
Er wordt geen paniekmelding weergegeven en het systeem schakelt normaal uit. Beide kernels zijn van deze boomstructuur.
defconfig plus CONFIG_CAN_SLCAN=y, met als enige verschil dit onderdeel.
Origineel (Engels) tonen
In the Linux kernel, the following vulnerability has been resolved:
net/packet: guard the ll header push in packet_rcv_spkt()
packet_rcv_spkt() restores the link layer header with
skb_push(skb, skb->data - skb_mac_header(skb));
That subtraction is only meaningful when the device actually has a link
layer header. packet_rcv() and tpacket_rcv() both wrap it in
dev_has_header(), which is also the predicate the block comment at the
top of the file states the restore in terms of; packet_rcv_spkt() does
not. commit d549699048b4 ("net/packet: fix packet receive on L3
devices without visible hard header") introduced the helper and changed
the two call sites, and this one stayed behind.
A device without a visible ll header can leave skb->mac_header at the
0xFFFF sentinel that __alloc_skb() initialises it to. A CAN skb does:
init_can_skb() sets pkt_type and ip_summed but does not reset the
headers, and commit 9f10374bb024 ("can: remove private CAN skb
headroom infrastructure") dropped the skb_reset_*_header() calls that
used to be there. skb_mac_header() is then 0xFFFF, the length becomes
a large negative number and skb_push() reports it through
skb_under_panic() -- from softirq context, so it is a full system panic
even with 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:
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
The socket type is reachable: packet_create() accepts SOCK_PACKET
alongside SOCK_RAW and SOCK_DGRAM behind the same CAP_NET_RAW check,
and neither the socket length nor a capability check keeps it away
from a CAN interface.
The missing skb_reset_*_header() calls in init_can_skb() are a
regression in their own right and are being fixed separately, but a
packet socket should not turn a link layer that did not initialise its
mac header into a kernel panic. Guard the push the way the other two
receive paths do.
Tested on v7.3-rc5 under QEMU with a slcan device on a pty, which is
the driver RX path: vcan does not reproduce it, because can_send()
resets the headers on the way out. One SOCK_PACKET socket bound to
can0 and one frame written into the line discipline panics an
unpatched kernel with the trace above; the same image with this patch
prints no panic and powers off normally. Both kernels are this tree,
defconfig plus CONFIG_CAN_SLCAN=y, differing only in this hunk.