CVE-2026-99081 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
bnxt_en: DMA-Mapping-Länge für gepaddete kleine Pakete korrigieren
Stefan Fleischmann meldete Intel-IOMMU-DMA-Lesefehler auf BCM57412-NetXtreme-E-NICs beim Senden von Paketen über VLAN/macvlan-Schnittstellen:
DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000
[fault reason 0x06] PTE Read access is not set
bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001
... NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out
Die Fehleradresse (0xfc499000) liegt auf einer exakten 4-KB-Seitengrenze und weist auf einen DMA-Lese-Pufferüberlauf hin.
In bnxt_start_xmit() werden Pakete, die kleiner als BNXT_MIN_PKT_SIZE (52 Bytes) sind, wie z.B. 42-Byte ungekennzeichnete ARP-Frames, gepaddet:
if (length < BNXT_MIN_PKT_SIZE) {
pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; }
mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ... dma_unmap_len_set(tx_buf, len, len);
Allerdings wurde 'len' zuvor mit skb_headlen(skb) (z.B. 42 Bytes) initialisiert und nach dem Padding nicht angepasst. Folglich werden bei dma_map_single() und dma_unmap_len_set() nur 42 Bytes gemappt bzw. verfolgt.
Später wird der Hardware-TX-Pufferdeskriptor mit der gepaddeten Länge programmiert:
txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END);
Der NIC-DMA-Engine wird somit befohlen, 52 Bytes aus einem Bereich zu lesen, in dem nur 42 Bytes DMA-gemappt wurden. Wenn skb->data nahe der Grenze einer 4-KB-Seite endet (innerhalb von 'pad' Bytes zur nächsten Seite), läuft die Hardware beim DMA-Lesezugriff über den gemappten Bereich hinaus auf die nicht gemappte angrenzende Seite und löst einen IOMMU-Fehler aus.
Dieses Problem wurde nach dem Commit 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") sichtbar, da das Reservieren von zusätzlichem VLAN-Headroom LL_RESERVED_SPACE von 48 auf 64 Bytes erhöhte, was die Offset-Werte für skb->data verschob und potenziell dazu führte, dass kleine Frames direkt an Seitengrenzen landeten.
Beheben Sie dies, indem Sie in bnxt_start_xmit() vor dem Abfragen von skb_shinfo(skb)->nr_frags skb_put_padto(skb, BNXT_MIN_PKT_SIZE) verwenden, da das Padding den skb linearisieren kann. Dies stellt sicher, dass skb->len und skb_headlen(skb) die gepaddete Größe widerspiegeln, sodass dma_map_single() den gesamten Puffer mappt und die Deskriptorlänge konsistent ist. Dadurch wird auch die temporäre Variable 'pad' sowie die Maskierungslogik entfernt.
Das Padding erfolgt nach dem SW-USO-Zweig (SW USO branch), da andernfalls bnxt_sw_udp_gso_xmit() das Padding als UDP-Nutzlast berücksichtigen und diese in zusätzlichen Segmenten senden würde.
Beachten Sie, dass SW-USO-Segmente weiterhin nicht gepaddet werden: Bei IPv4 wird ein Segment mit weniger als 10 Bytes UDP-Nutzlast (kleine gso_size oder ein kurzes letztes Segment) als Frame gesendet, der kürzer ist als BNXT_MIN_PKT_SIZE. Dies ist ein separates Problem und bleibt für einen nachfolgenden Patch übrig.
Once again VulDB remains the best source for vulnerability data.