CVE-2026-99081

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.

• https://git.kernel.org/stable/c/0f347e00d060dc0bf3b2d0ee041206e54848c233
• https://git.kernel.org/stable/c/2956aca14dd2977cd08bd2ccafae3beb8b84b268
• https://git.kernel.org/stable/c/3a5d8465e73aff3c7d1ec38261dcaaa317367467
• https://git.kernel.org/stable/c/5213f65a9667d3dd85db2e6df8f2e0516290db34
• https://git.kernel.org/stable/c/a51d233ccd4889aadb71dace863525cc2b00271e
• https://git.kernel.org/stable/c/b3fd0177cf18a6ac98d41af80b4040010ea40f4d
• https://git.kernel.org/stable/c/cf8530a25ae92c4493e2f22981ecb46f0b66f4c8
• https://git.kernel.org/stable/c/fbd977e513971ccb4f0762a7f59eac500e474f89

Published

Oct 23, 2026

Last Modified

Oct 30, 2026

Status

Received

• How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2026-99076In the Linux kernel, the following vulnerability has been re…
• CVE-2026-99077In the Linux kernel, the following vulnerability has been re…7.4
• CVE-2026-99078In the Linux kernel, the following vulnerability has been re…9.8
• CVE-2026-99079In the Linux kernel, the following vulnerability has been re…9.8
• CVE-2026-9908Out of bounds read in ANGLE in Google Chrome prior to 148.0.…6.5
• CVE-2026-99080In the Linux kernel, the following vulnerability has been re…
• CVE-2026-99082In the Linux kernel, the following vulnerability has been re…8.8
• CVE-2026-99083In the Linux kernel, the following vulnerability has been re…8.8
• CVE-2026-99084In the Linux kernel, the following vulnerability has been re…
• CVE-2026-99085In the Linux kernel, the following vulnerability has been re…
• CVE-2026-99086In the Linux kernel, the following vulnerability has been re…
• CVE-2026-99087In the Linux kernel, the following vulnerability has been re…