Linux Kernel bis 7.3-rc4 af_packet prb_calc_retire_blk_tmo tp_block_size Pufferüberlauf

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.2$0-$5k0.91-

Zusammenfassunginfo

In Linux Kernel bis 7.3-rc4 wurde eine kritische Schwachstelle entdeckt. Dabei betrifft es die Funktion prb_calc_retire_blk_tmo der Komponente af_packet. Mittels dem Manipulieren des Arguments tp_block_size mit unbekannten Daten kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. Diese Schwachstelle trägt die Bezeichnung CVE-2026-98547. Der Angriff kann über das Netzwerk passieren. Es gibt keinen verfügbaren Exploit. Die Aktualisierung der betroffenen Komponente wird empfohlen.

Detailsinfo

Eine kritische Schwachstelle wurde in Linux Kernel bis 7.3-rc4 entdeckt. Betroffen davon ist die Funktion prb_calc_retire_blk_tmo der Komponente af_packet. Dank der Manipulation des Arguments tp_block_size mit einer unbekannten Eingabe kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-190. Das hat Auswirkungen auf die Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: af_packet: fix integer overflow in prb_calc_retire_blk_tmo() prb_calc_retire_blk_tmo() computes in 32-bit int arithmetic: mbits = (blk_size_in_bytes * 8) / (1024 * 1024); If I'm reading the validation right, tp_block_size is user controlled and packet_set_ring() only rejects values that are <= 0 as int or not page aligned, so a 256MiB block goes right through (and alloc_one_pg_vec_page() even has a vzalloc fallback for it). 0x10000000 * 8 wraps to INT_MIN, and on a NIC reporting 1 Gbps (div == 1) the function ends up returning -2047. The condition is actually (8 * size) mod 2^32 >= 2^31 && div == 1, so the trigger set is [256,512), [768,1024), [1280,1536) and [1792,2048) MiB. Other sizes wrap to non-negative values and faster links divide the unsigned value back below 2^31, which is why this doesn't blow up for everyone. What makes it fatal is what happens next in init_prb_bdqc(): p1->interval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...)); hrtimer_start(&p1->retire_blk_timer, p1->interval_ktime, HRTIMER_MODE_REL_SOFT); A negative relative timeout expires immediately. The callback unconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns the negative interval into hrtimer_resolution: if (interval < hrtimer_resolution) interval = hrtimer_resolution; So the SOFT timer re-fires at the maximum rate forever, holding sk_receive_queue.lock each pass. One CPU spins in softirq until the socket is closed. Repeat with more rings and the machine is gone. The overflow itself is ancient - it was introduced together with TPACKET_V3 in f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation."). Its effect prior to f7460d2989fa ("net: af_packet: Use hrtimer to do the retire operation", v6.18) was not as clear-cut, though: the return value was stored into an unsigned short retire_blk_tov, so a negative result was truncated, and a 0-jiffy delay loop could be programmed as well. Neither is nearly as detrimental as the immediate maximum-rate spin the hrtimer conversion turned it into. (Unrelated to CVE-2019-20812 - that one was the ethtool failure path returning 0, which now returns DEFAULT_PRB_RETIRE_TOV.) Reproducer, needs CAP_NET_RAW (a --network host container has it by default) and a 1 Gbps NIC (QEMU e1000 works): int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); bind(fd, ...); int v = TPACKET_V3; setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v)); struct tpacket_req3 req = { .tp_block_size = 0x10000000, .tp_block_nr = 1, .tp_frame_size = 2048, .tp_frame_nr = 0x10000000 / 2048, .tp_retire_blk_tov = 0, }; setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &req, sizeof(req)); Compute in 64 bits instead. The operands are already bounded by the existing validation, so nothing else changes. If you'd prefer a different fix, just say so and I'll respin.

Das Advisory kann von git.kernel.org heruntergeladen werden. Die Identifikation der Schwachstelle findet seit dem 25.09.2026 als CVE-2026-98547 statt. Das Ausnutzen gilt als leicht. Der Angriff kann über das Netzwerk passieren. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht. Es muss davon ausgegangen werden, dass ein Exploit zur Zeit etwa USD $0-$5k kostet (Preisberechnung vom 18.10.2026).

Ein Upgrade auf die Version 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.55, 7.2.9 oder 7.3-rc5 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches eb5b3838b9200dac04bfe33483db0ee8287456fb/297acc571d5813db76b147c745b91031d5f9c960/be1aacff399d519cc48d6b34354a54dd79041140/b2bcc6a254d6f27823a56787668ae4ee8cdb6e71/6279211e7d2456ecd195d236c9ee5e5c6fa5a17a/218a944b9e035d4b47d59c69af6ca13319da15fb/56d82862a0a243ac14ba11b6d7b57ddc2d064b95 beheben. Als bestmögliche Massnahme wird das Aktualisieren auf eine neue Version empfohlen.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 6.5
VulDB Meta Temp Score: 6.2

VulDB Base Score: 6.5
VulDB Temp Score: 6.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-190 / CWE-189
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 5.10.271/5.15.222/6.1.189/6.6.158/6.12.112/6.18.55/7.2.9/7.3-rc5
Patch: eb5b3838b9200dac04bfe33483db0ee8287456fb/297acc571d5813db76b147c745b91031d5f9c960/be1aacff399d519cc48d6b34354a54dd79041140/b2bcc6a254d6f27823a56787668ae4ee8cdb6e71/6279211e7d2456ecd195d236c9ee5e5c6fa5a17a/218a944b9e035d4b47d59c69af6ca13319da15fb/56d82862a0a243ac14ba11b6d7b57ddc2d064b95

Timelineinfo

25.09.2026 CVE zugewiesen
18.10.2026 +23 Tage Advisory veröffentlicht
18.10.2026 +0 Tage VulDB Eintrag erstellt
18.10.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-98547 (🔒)
GCVE (CVE): GCVE-0-2026-98547
GCVE (VulDB): GCVE-100-422048

Eintraginfo

Erstellt: 18.10.2026 20:02
Anpassungen: 18.10.2026 20:02 (60)
Komplett: 🔍
Cache ID: 216::103

VulDB is the best source for vulnerability data and more expert information about this specific topic.

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!