{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-99081 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2026-99081 is a high-severity vulnerability in Linux, published on 23 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-99081 and fix it if it is affected.\n\nWhat it is: CVE-2026-99081 is a high-severity vulnerability in Linux, published on 23 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-99081 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-99081/ (Markdown: https://insights.sbomify.com/CVE-2026-99081/index.md)","id":"CVE-2026-99081","markdown":"https://insights.sbomify.com/CVE-2026-99081/index.md","name":"CVE-2026-99081","record":{"aliases":["AZL-110984","BELL-CVE-2026-99081","DEBIAN-CVE-2026-99081","GHSA-9368-hxmw-4c4j","UBUNTU-CVE-2026-99081"],"analysis":null,"analysis_generated_by":null,"assigner":"Linux","cpe":[],"cvss":{"score":7.5,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: fix DMA mapping length for padded small packets\n\nStefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412\nNetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces:\n\n  DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000\n        [fault reason 0x06] PTE Read access is not set\n  bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001\n  ...\n  NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out\n\nThe fault address (0xfc499000) is on an exact 4KB page boundary,\npointing to a DMA read buffer overrun.\n\nIn bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes),\nsuch as 42-byte untagged ARP frames, are padded:\n\n    if (length \u003c BNXT_MIN_PKT_SIZE) {\n        pad = BNXT_MIN_PKT_SIZE - length;\n        if (skb_pad(skb, pad))\n            goto tx_kick_pending;\n        length = BNXT_MIN_PKT_SIZE;\n    }\n\n    mapping = dma_map_single(\u0026pdev-\u003edev, skb-\u003edata, len, DMA_TO_DEVICE);\n    ...\n    dma_unmap_len_set(tx_buf, len, len);\n\nHowever, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes)\nand is left unadjusted after padding. Consequently, dma_map_single() and\ndma_unmap_len_set() map and track only 42 bytes.\n\nLater, the hardware TX buffer descriptor is programmed with the padded length:\n\n    txbd-\u003etx_bd_len_flags_type =\n        cpu_to_le32(((len + pad) \u003c\u003c TX_BD_LEN_SHIFT) | flags |\n                    TX_BD_FLAGS_PACKET_END);\n\nThe NIC DMA engine is thus instructed to read 52 bytes from a region where\nonly 42 bytes were DMA-mapped. If skb-\u003edata ends near the boundary of a 4KB\npage (within 'pad' bytes of the next page), the hardware DMA read overruns\ninto the unmapped adjacent page, triggering an IOMMU fault.\n\nThis issue was exposed after commit 447cbe95ebb9 (\"vlan: fix skb_under_panic\nand races when toggling HW VLAN offload\") because reserving extra VLAN\nheadroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes, shifting skb-\u003edata\noffsets and potentially causing small frames to land right against page\nboundaries.\n\nFix this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in\nbnxt_start_xmit(), before skb_shinfo(skb)-\u003enr_frags is sampled,\nbecause padding might linearize the skb.\nThis ensures skb-\u003elen and skb_headlen(skb) reflect the padded size so\nthat dma_map_single() maps the full buffer and the descriptor length is\nconsistent. This also removes the temporary 'pad' variable and masking logic.\n\nThe padding is done after the SW USO branch, otherwise\nbnxt_sw_udp_gso_xmit() would account the padding as UDP payload\nand send it in extra segments.\n\nNote that SW USO segments are still not padded: with IPv4, a segment\ncarrying less than 10 bytes of UDP payload (small gso_size, or a short\nlast segment) is sent as a frame shorter than BNXT_MIN_PKT_SIZE.\nThis is a separate issue, left for a followup patch.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"bnxt_en: fix DMA mapping length for padded small packets","id":"CVE-2026-99081","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":5,"next":{"headline":"KVM: x86: Use active memslots for the per-vCPU MMIO cache","id":"CVE-2026-99082"},"packages":[],"prev":{"headline":"fs: Free any excess xarray nodes in clear_inode()","id":"CVE-2026-99080"},"products":["Linux"],"published":"2026-10-23","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-24","vendors":["Linux"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-99081/"}