bnxt_en: fix DMA mapping length for padded small packets
Affects the bnxt_en driver on Broadcom BCM57412 NetXtreme-E NICs sending small packets on VLAN or macvlan interfaces. Linux kernel fixes are listed per stable branch, starting at 6.6.160.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 6.6.160, 6.12.113, 6.18.57, 7.2.11
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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 < 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); 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) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 bytes were DMA-mapped. If skb->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.
Timeline
- CVE published
- First seen by cve.now
- Record last updated
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
4.4
- KernelLinux
From 4.4.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.12.113; From 6.13.0 · fixed in 6.18.57; From 6.19.0 · fixed in 7.2.11
References 8
git.kernel.org
- stable/c/0f347e00d060dc0bf3b2d0ee041206e54848c233
- stable/c/b3fd0177cf18a6ac98d41af80b4040010ea40f4d
- stable/c/3a5d8465e73aff3c7d1ec38261dcaaa317367467
- stable/c/cf8530a25ae92c4493e2f22981ecb46f0b66f4c8
- stable/c/2956aca14dd2977cd08bd2ccafae3beb8b84b268
- stable/c/fbd977e513971ccb4f0762a7f59eac500e474f89
- stable/c/5213f65a9667d3dd85db2e6df8f2e0516290db34
- stable/c/a51d233ccd4889aadb71dace863525cc2b00271e
Questions about CVE-2026-99081
What does this mean?
The driver pads transmitted packets smaller than 52 bytes, but the DMA mapping used the wrong length for the padded packet. The hardware then reads past the end of the mapped memory into an adjacent unmapped page, which can cause IOMMU faults, firmware abandoning messages and transmit queue timeouts.Source: git.kernel.org
Am I affected, and how do I check?
Kernels from 4.4.0 up to the fixed versions 6.6.160, 6.12.113, 6.18.57 and 7.2.11 on their respective branches are listed as affected. The issue needs a BCM57412 NetXtreme-E NIC using the bnxt_en driver, with VLAN or macvlan interfaces. The exposure followed commit 447cbe95ebb9, so check the kernel version and whether the lspci output shows a BCM57412 device.Source: git.kernel.org
What should I do about it?
Update the Linux kernel to the fixed release for your branch: 6.6.160, 6.12.113, 6.18.57, or 7.2.11 or later. No fixed version is given for kernels before 6.6 in the checked facts.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data