CVE-2026-99081
No exploitation reported by the sources we read.
- Published2026-10-23
Am I affected?
Debian, Ubuntu or Red Hat sometimes backport a fix without changing the upstream version number: such a version reads « to verify », never « affected ».With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.
Description
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
dates in UTC- 2026-10-2313:17CVE publishedNVD
Observed activity
isMalicious corpus · updated 2026-10-24 15:37 UTCBlock these indicators
- Firewall list (EDL, text): https://api.ismalicious.com/edl/cve/CVE-2026-99081?format=txt
- CSV export: https://api.ismalicious.com/edl/cve/CVE-2026-99081?format=csv
- TAXII collection of exploited CVEs
- The EDL and CSV take an API key on the Pro plan.
Versions per branch
Neither OSV.dev nor the vendor advisories we read list affected versions for CVE-2026-99081 yet.
Fix
No fix published by the sources we read yet. NVD record
Detection
- Nuclei template
- none so far ProjectDiscovery
- Exploit-DB
- no entry Exploit-DB
- Proof-of-concept repositories
- none listed PoC-in-GitHub
Sources
Technical details
- CVSS v3 Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Published
- 2026-10-23
- Last Modified
- 2026-10-24
- NVD status
- Received
Frequently asked questions
What is CVE-2026-99081?
Is CVE-2026-99081 actively exploited?
What is the CVSS score for CVE-2026-99081?
Running Linux kernel? Hear about its next vulnerability
Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».
No credit card required · No monthly cap on website lookups · 250 API requests/month
Go further
- Following what attackers exploit right now? The CISA KEV additions of the month, with their patch deadlines.
- Running this software? Vulnerability monitoring alerts you to new vulnerabilities in your products.
Related vulnerabilities
Same product first, then the same vendor advisory and the same publication week.
- CVE-2026-114625KEVsame weekSecurity Advisory 0199
- CVE-2026-109618same week
- CVE-2026-109619same week
- CVE-2026-113802same week
- CVE-2026-112195same weekFusionPBX Dialplan Editor dialplan.php os command injection
- CVE-2026-113391same weekDrayTek Vigor2960 Upload Endpoint mainfunction.cgi uploadlangs command injection
- CVE-2026-114575same weekTOTOLINK A950RG product.so UploadCustomModule command injection
- CVE-2026-113390same weekDrayTek Vigor2960 CGI mainfunction.cgi sub_182B0 os command injection