CVE-2026-99081 in Linux
Summary
by MITRE • 10/23/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in the Linux kernel driver bnxt_en involves an incorrect DMA mapping length when transmitting small packets on VLAN and macvlan interfaces. This flaw leads to Direct Memory Access read faults triggered by Intel IOMMU systems, specifically affecting BCM57412 NetXtreme-E network interface cards. The root cause lies in a mismatch between the amount of memory mapped for DMA operations and the actual length of data programmed into the hardware transmit buffer descriptors. When packets smaller than BNXT_MIN_PKT_SIZE are transmitted, such as 42-byte untagged ARP frames, the driver pads them to meet minimum size requirements but fails to update the DMA mapping length accordingly. This discrepancy causes the network interface card's DMA engine to read beyond the mapped memory region into adjacent unmapped pages, resulting in IOMMU faults and subsequent transmit queue timeouts that disrupt network connectivity.
Technically, the flaw exists within the bnxt_start_xmit function where packet padding logic is implemented incorrectly relative to DMA mapping procedures. The code calculates a pad value based on the difference between BNXT_MIN_PKT_SIZE and the current packet length, then applies this padding using skb_pad. However, while the variable len is updated to reflect the padded size for hardware descriptor programming via cpu_to_le32 operations, it was initialized earlier as skb_headlen(skb) and not adjusted before calling dma_map_single. Consequently, only the original smaller byte count is mapped in physical memory. When the NIC attempts to read the full padded length from this insufficiently mapped buffer, especially if the data ends near a 4KB page boundary, it triggers a DMA Read NO_PASID fault with reason code indicating PTE Read access is not set. This specific issue was exacerbated by commit 447cbe95ebb9 which increased LL_RESERVED_SPACE for VLAN offload handling, shifting skb->data offsets and increasing the likelihood of small frames aligning precisely against page boundaries where such overruns become fatal to system stability.
The operational impact includes severe network instability characterized by persistent DMA read faults logged in kernel messages like DMAR errors and NETDEV WATCHDOG timeouts indicating transmit queue stalls. These events can lead to complete loss of network connectivity for the affected interface as the driver abandons transmission messages due to firmware status errors. The vulnerability effectively allows local conditions or specific traffic patterns involving small packets on VLAN interfaces to cause denial of service through hardware-level faults that crash or stall the networking subsystem. This represents a significant reliability issue in enterprise environments relying on Intel IOMMU for memory protection and virtualization support, as it undermines the integrity guarantees provided by such systems when dealing with standard network protocol frames like ARP.
Mitigation strategies involve applying kernel patches that correct the DMA mapping logic to ensure consistency between mapped buffer sizes and hardware descriptor lengths. The primary fix utilizes skb_put_padto instead of manual padding calculations followed by separate length adjustments, ensuring that both skb->len and skb_headlen reflect the true padded size before dma_map_single is invoked. This approach guarantees that the entire transmitted frame resides within a properly mapped memory region regardless of page boundary alignment. Additionally, developers should monitor for related issues regarding software UDP segmentation offload segments which may still transmit frames shorter than BNXT_MIN_PKT_SIZE without proper padding, representing a separate but potentially exploitable vector requiring future attention. System administrators can temporarily mitigate risks by disabling VLAN hardware offloading features if immediate patching is not feasible, though this reduces performance and does not address the underlying driver defect completely.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input in C which describes classic buffer overflow scenarios arising from incorrect size assumptions during memory operations. In terms of attack vectors, it relates to ATT&CK technique T1498 Network Denial of Service where an attacker or misconfigured system triggers resource exhaustion through hardware faults rather than traditional software crashes. The incident highlights the critical importance of maintaining consistency between logical packet sizes and physical DMA mappings in high-performance network drivers, particularly when dealing with variable-length frames common in modern networking stacks involving VLAN tagging and segmentation offloads.