Bug 2559802 (CVE-2026-99081)
| Summary: | CVE-2026-99081 kernel: bnxt_en: fix DMA mapping length for padded small packets | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | akhatavk, aos-team-art-private, asdas, daniel.helgenberger, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, redhat, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in the Linux kernel's Broadcom NetXtreme-E (bnxt_en) network driver, which can lead to a Denial of Service (DoS). When transmitting small network packets that require padding, the driver fails to update the Direct Memory Access (DMA) mapping length to account for the padded size. As a result, the network controller can read beyond the mapped memory buffer into unmapped memory, triggering an Input-Output Memory Management Unit (IOMMU) fault. An attacker capable of generating or transmitting small network packets across affected interfaces can exploit this vulnerability to trigger transmit queue timeouts and disrupt network connectivity.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Alma already has the patch in their kernels: https://git.almalinux.org/rpms/kernel/src/tag/changed/a10/kernel-6.12.0-211.73.1.el10_2/2017-bnxt_en-fix-DMA-mapping-length-for-padded-small-pack.patch And Debian also has the upstream-fix. Please consider having it since it not only leads to occasional crashes "now and then" but can be triggered remotely. Additional data point: this issue reproduces reliably on a RHEL 10.2 rebuild (Rocky Linux 10) with a Broadcom BCM57416 on an AMD EPYC host. It started after the VLAN fix (CVE-2026-80925, RHEL-254268) was backported in kernel-6.12.0-211.64.1.el10_2. Environment: - Supermicro H13SSW, AMD EPYC 9374F, AMD IOMMU in translated mode (default) - NIC: Broadcom BCM957416N4160C (BCM57416, OCP 3.0, 2x 10GBASE-T) FW pkg 226.1.107.0, mgmt 226.0.145.0 - bnxt_en (in-tree), both ports in an 802.3ad bond, with an 802.1Q VLAN interface (id 158) on top - Affected kernels: 6.12.0-211.64.1, 211.66.1, 211.68.1, 211.69.1.el10_2 - 6.12.0-211.73.1.el10_2 does not contain the fix either (no corresponding bnxt_en entry in its changelog) Timeline: - Up to 211.59.1 (no "vlan: fix skb_under_panic..." backport): stable, no incidents - From 211.64.1 onwards: NIC failures every 1-14 hours, with the frequency increasing over time Sequence of every incident (kernel log): bnxt_en 0000:81:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x001f address=0xecddf000 flags=0x0000] bnxt_en 0000:81:00.1 enp129s0f1np1: Fatal firmware reset event, data1: 0x201, data2: 0xda27, min wait 1300 ms, max wait 4200 ms bnxt_en 0000:81:00.0 enp129s0f0np0: Abandoning msg {0x23 0x3cab} len: 0 due to firmware status: 0x2000001 bnxt_en 0000:81:00.0 enp129s0f0np0: NETDEV WATCHDOG: CPU: 7: transmit queue 14 timed out 5004 ms bnxt_en 0000:81:00.0 enp129s0f0np0: hwrm req_type 0xb1 ... error 0x3 bnxt_en 0000:81:00.0 enp129s0f0np0: hwrm stat ctx alloc failure rc: fffffff3 bnxt_en 0000:81:00.0 enp129s0f0np0: nic open fail (rc: fffffff3) bond0: now running without any active interface! The faulting IOVA is page-aligned (0xecddf000). This is consistent with the NIC reading past the end of a short DMA mapping into the next, unmapped page, as described in this CVE. The resulting DMA error makes the NIC firmware go into a fatal reset. The driver's automatic recovery often fails ("stat ctx alloc failure"), and since both ports sit on the same ASIC, the host loses all network connectivity until manual intervention (modprobe -r/modprobe bnxt_en, or a reboot). Workaround: booting with iommu=pt. Please backport upstream commit a51d233ccd48 ("bnxt_en: fix DMA mapping length for padded small packets") to RHEL 10.2 z-stream. The backport of CVE-2026-80925 in 211.64.1 makes this bug readily triggerable on VLAN setups. On a system that got triggered repeatedly we've temporarily deployed the current kernel-package from Almalinux that includes the fix already as well. And the system has been fully stable since then. Looking forward to having the fix in RHEL10. |
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.