CVE-2026-99081
Beschrijving NL
In de Linux-kernel is de volgende kwetsbaarheid verholpen:
bnxt_en: corrigeer de DMA-mappinglengte voor kleine, opgevulde pakketten
Stefan Fleischmann meldde Intel IOMMU DMA-leesfouten op BCM57412.
NetXtreme-E NIC's bij het verzenden van pakketten via VLAN/macvlan-interfaces:
DMAR: [DMA Read NO_PASID] Verzoekapparaat [18:00.0] foutadres 0xfc499000
[foutreden 0x06] PTE-leestoegang is niet ingesteld
bnxt_en 0000:18:00.0 eno1np0: Bericht {0xb4 0x41a} lengte: 0 wordt afgebroken vanwege firmware status: 0x2000001
... NETDEV WATCHDOG: eno1np0 (bnxt_en): verzendwachtrij 0 heeft een time-out bereikt
Het foutadres (0xfc499000) bevindt zich precies op een paginagrens van 4KB.
Dit wijst op een DMA-leesbufferoverloop. In bnxt_start_xmit() worden pakketten kleiner dan BNXT_MIN_PKT_SIZE (52 bytes) verzonden.
Zoals bijvoorbeeld 42-byte ARP-frames zonder tags, worden deze opgevuld:
als (lengte dev, skb->data, len, DMA_TO_DEVICE);
... dma_unmap_len_set(tx_buf, len, len);
Echter, 'len' werd eerder geïnitialiseerd naar skb_headlen(skb) (bijv. 42 bytes)
en wordt na het opvullen niet aangepast. Bijgevolg dma_map_single() en
dma_unmap_len_set() kaart en volg slechts 42 bytes. Later wordt de hardware TX-bufferdescriptor geprogrammeerd met de opgevulde lengte:
txbd->tx_bd_len_flags_type =
cpu_to_le32(((len + pad) <data eindigt bij de grens van een 4KB
pagina (binnen 'pad' bytes van de volgende pagina), de hardware DMA lees overschrijdingen
in de niet-toegewezen aangrenzende pagina, waardoor een IOMMU-fout wordt veroorzaakt. This issue was exposed after commit 447cbe95ebb9 ("vlan: fix skb_under_panic
and races when toggling HW VLAN offload") because reserving extra VLAN
headroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes, shifting skb->data
offsets and potentially causing small frames to land right against page
boundaries. Fix this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in
bnxt_start_xmit(), before skb_shinfo(skb)->nr_frags is sampled,
because padding might linearize the skb. This ensures skb->len and skb_headlen(skb) reflect the padded size so
that dma_map_single() maps the full buffer and the descriptor length is
consistent. This also removes the temporary 'pad' variable and masking logic. The padding is done after the SW USO branch, otherwise
bnxt_sw_udp_gso_xmit() would account the padding as UDP payload
and send it in extra segments. Note that SW USO segments are still not padded: with IPv4, a segment
carrying less than 10 bytes of UDP payload (small gso_size, or a short
last segment) is sent as a frame shorter than BNXT_MIN_PKT_SIZE. This is a separate issue, left for a followup patch.
Origineel (Engels) tonen
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: fix DMA mapping length for padded small packets
Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412
NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces:
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
The fault address (0xfc499000) is on an exact 4KB page boundary,
pointing to a DMA read buffer overrun.
In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes),
such as 42-byte untagged ARP frames, are padded:
if (length dev, skb->data, len, DMA_TO_DEVICE);
...
dma_unmap_len_set(tx_buf, len, len);
However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes)
and is left unadjusted after padding. Consequently, dma_map_single() and
dma_unmap_len_set() map and track only 42 bytes.
Later, the hardware TX buffer descriptor is programmed with the padded length:
txbd->tx_bd_len_flags_type =
cpu_to_le32(((len + pad) <data ends near the boundary of a 4KB
page (within 'pad' bytes of the next page), the hardware DMA read overruns
into the unmapped adjacent page, triggering an IOMMU fault.
This issue was exposed after commit 447cbe95ebb9 ("vlan: fix skb_under_panic
and races when toggling HW VLAN offload") because reserving extra VLAN
headroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes, shifting skb->data
offsets and potentially causing small frames to land right against page
boundaries.
Fix this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in
bnxt_start_xmit(), before skb_shinfo(skb)->nr_frags is sampled,
because padding might linearize the skb.
This ensures skb->len and skb_headlen(skb) reflect the padded size so
that dma_map_single() maps the full buffer and the descriptor length is
consistent. This also removes the temporary 'pad' variable and masking logic.
The padding is done after the SW USO branch, otherwise
bnxt_sw_udp_gso_xmit() would account the padding as UDP payload
and send it in extra segments.
Note that SW USO segments are still not padded: with IPv4, a segment
carrying less than 10 bytes of UDP payload (small gso_size, or a short
last segment) is sent as a frame shorter than BNXT_MIN_PKT_SIZE.
This is a separate issue, left for a followup patch.