Cloudanix VulnDB

CVE-2026-99081

High · 7.5

CVSS

7.5

EPSS

0.5%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A driver bug in certain network cards could cause the system to read memory it shouldn't when sending very small network messages, leading to connection hiccups until fixed by a kernel update.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Incorrect length passed to dma_map_single and dma_unmap_len_set after skb padding for packets below BNXT_MIN_PKT_SIZE causes the NIC TX descriptor to request a DMA read beyond the mapped buffer, overrunning into an adjacent unmapped page when skb->data is near a 4KB boundary.

Why it matters to the business

Network interface transmit timeouts and IOMMU faults on affected Broadcom NetXtreme-E adapters under routine small-packet traffic (ARP, etc.) on VLAN or macvlan setups, leading to brief connectivity loss and potential service degradation on systems using these NICs.

How an attack unfolds

An attacker or normal traffic generates untagged frames smaller than 52 bytes (e.g., 42-byte ARP) on a VLAN/macvlan interface; the driver pads the skb but fails to update the length variable used for DMA mapping; the hardware then attempts a DMA read past the mapped region, triggering an IOMMU fault and watchdog timeout when the frame lands near a page boundary.

How to fix it

Update the Linux kernel to a version containing the bnxt_en fix that replaces the manual padding logic with skb_put_padto before sampling nr_frags and length; ensure the change is present after commit 447cbe95ebb9 effects.

How to confirm the fix worked

Confirm the patched bnxt_start_xmit uses skb_put_padto for minimum packet size and that dma_map_single receives skb->len after padding; reproduce small untagged ARP transmission on VLAN interfaces and verify absence of DMAR faults or NETDEV WATCHDOG messages.

Typical attack path

  1. Send or trigger transmission of a packet smaller than BNXT_MIN_PKT_SIZE on a VLAN or macvlan interface
  2. Driver enters padding path in bnxt_start_xmit but leaves 'len' at original skb_headlen value
  3. dma_map_single maps only the original short length while TX BD is programmed with padded length
  4. NIC DMA engine reads past mapped region into unmapped page
  5. IOMMU fault logged and transmit queue watchdog fires, abandoning the message

How to detect it

Search kernel logs and dmesg for DMAR DMA Read faults referencing bnxt_en devices, NETDEV WATCHDOG transmit queue timeouts on eno* interfaces, and firmware status 0x2000001 messages; correlate with VLAN or macvlan interface usage and small outbound frames.

  • DMAR: [DMA Read NO_PASID] Request device
  • bnxt_en.*Abandoning msg.*firmware status: 0x2000001
  • NETDEV WATCHDOG:.*transmit queue.*timed out
  • fault addr.*PTE Read access is not set

What your security team should do

  • Prioritize kernel updates on systems with BCM57412 or similar bnxt_en NICs within standard change windows given low EPSS and no KEV listing
  • Monitor dmesg and IOMMU logs for DMAR read faults and transmit queue timeouts on bnxt_en interfaces
  • Test VLAN and macvlan configurations with small frames after patching to validate the DMA length fix

The record

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.

Affected packages

Ecosystem Package Introduced Fixed