Linux Kernel bis 6.6.159/6.12.112/6.18.56/7.2.10 Packet Socket Receive net/core/skbuff.c packet_rcv_spkt Pufferüberlauf

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
7.2$5k-$25k0.79+

Zusammenfassunginfo

Es wurde eine kritische Schwachstelle in Linux Kernel bis 6.6.159/6.12.112/6.18.56/7.2.10 ausgemacht. Es geht dabei um die Funktion packet_rcv_spkt der Datei net/core/skbuff.c der Komponente Packet Socket Receive. Dank der Manipulation mit unbekannten Daten kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. Diese Verwundbarkeit ist als CVE-2026-99033 gelistet. Der Angriff kann über das Netzwerk passieren. Es existiert kein Exploit. Ein Upgrade der betroffenen Komponente wird empfohlen.

Detailsinfo

Eine Schwachstelle wurde in Linux Kernel bis 6.6.159/6.12.112/6.18.56/7.2.10 entdeckt. Sie wurde als kritisch eingestuft. Dies betrifft die Funktion packet_rcv_spkt der Datei net/core/skbuff.c der Komponente Packet Socket Receive. Mittels dem Manipulieren mit einer unbekannten Eingabe kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-120. Auswirkungen hat dies auf die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

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: <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 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.

Bereitgestellt wird das Advisory unter git.kernel.org. Die Verwundbarkeit wird seit dem 25.09.2026 mit der eindeutigen Identifikation CVE-2026-99033 gehandelt. Die Ausnutzbarkeit ist als leicht bekannt. Umgesetzt werden kann der Angriff über das Netzwerk. Das Ausnutzen erfordert keine spezifische Authentisierung. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht. Ein Exploit zur Schwachstelle wird momentan etwa USD $5k-$25k kosten (Preisberechnung vom 23.10.2026).

Ein Aktualisieren auf die Version 6.6.160, 6.12.113, 6.18.57 oder 7.2.11 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches d8a24b9e1774a93943caf68d48c5e17be432220b/31c7b15b3716e8d0dad58d2c3cdf321dfd06f4be/3efe0e0944157fdd2072b4dc7eb0491a317ed272/00fbf71e74115f7628fc0880b855434b1e70c40c/28bc1ef699610ee09ce3d46a00552f5a0a0144bd lösen. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 7.5
VulDB Meta Temp Score: 7.2

VulDB Base Score: 7.5
VulDB Temp Score: 7.2
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Pufferüberlauf
CWE: CWE-120 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.6.160/6.12.113/6.18.57/7.2.11
Patch: d8a24b9e1774a93943caf68d48c5e17be432220b/31c7b15b3716e8d0dad58d2c3cdf321dfd06f4be/3efe0e0944157fdd2072b4dc7eb0491a317ed272/00fbf71e74115f7628fc0880b855434b1e70c40c/28bc1ef699610ee09ce3d46a00552f5a0a0144bd

Timelineinfo

25.09.2026 CVE zugewiesen
23.10.2026 +28 Tage Advisory veröffentlicht
23.10.2026 +0 Tage VulDB Eintrag erstellt
23.10.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2026-99033 (🔒)
GCVE (CVE): GCVE-0-2026-99033
GCVE (VulDB): GCVE-100-425837

Eintraginfo

Erstellt: 23.10.2026 15:38
Anpassungen: 23.10.2026 15:38 (60)
Komplett: 🔍
Cache ID: 216::103

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!