Look up another CVE · open CVE-2026-93830 in the interactive tracker
CVE-2026-93830
net: stmmac: xgmac2: disable RBUE in default RX interrupt mask
Published 2026-09-24 (24 days ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-93830 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
- What this is
- STMMAC ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/stmicro/stmmac/ · netdev@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid, bookworm · linux-6.12?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-09-24 (24 days ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.49%, higher than 40.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.19 | 5.10.271 | 8c9d57b5dc09 |
| 4.19 | 5.15.222 | 7a10e54e42a8 |
| 4.19 | 6.1.189 | 6b3b91433d5f |
| 4.19 | 6.6.158 | 74dbb85a6a25 |
| 4.19 | 6.12.111 | 0b1a5d3647ce |
| 4.19 | 6.18.53 | 87e2826ed205 |
| 4.19 | 7.2 | d3265c19b35d |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- Inbound Ethernet frames (IPv4/IPv6 unicast to the host MAC) are DMA'd into the XGMAC2 RX ring; emptying it asserts XGMAC_RBU. With XGMAC_RBUE in XGMAC_DMA_INT_DEFAULT_RX, stmmac_interrupt/stmmac_msi_intr_rx → stmmac_napi_check → dwxgmac2_dma_interrupt runs. XGMAC2 is a 10G IP Ethernet MAC (Agilex5, Tegra MGBE, snps,dwxgmac).
- AC:LAttack complexity, low
- A remote flood is enough: DMA_DEFAULT_RX_SIZE is 512, and Agilex5 under heavy RX already produced 1,821,811,555 MAC IRQs versus 2,618,627 completions. The attacker sets arrival rate; no race or layout is required. The worse stall (page_pool_alloc_pages failure in stmmac_rx_refill) is also GFP_ATOMIC exhaustion from that flood.
- PR:NPrivileges required, none
- dwxgmac2_dma_interrupt runs from the XGMAC DMA hardirq (stmmac_interrupt or stmmac_msi_intr_rx) on received frames before any socket, netfilter verdict, or authentication check.
- UI:NUser interaction, none
- The attacker sends the frames themselves; stmmac_interrupt/stmmac_msi_intr_rx schedules NAPI via stmmac_napi_check with no local user action.
- S:UScope, unchanged
- The RBUE storm runs in the host kernel ISR/NAPI (stmmac_interrupt, dwxgmac2_dma_interrupt, stmmac_napi_poll_rx); it does not cross a VM, IOMMU, or sandbox boundary.
- C:NConfidentiality impact, none
- On XGMAC_RBU, dwxgmac2_dma_interrupt only increments x->rx_buf_unav_irq and returns handle_rx so NAPI runs; it does not read or return kernel memory to the sender.
- I:NIntegrity impact, none
- The RBU handler does not write attacker-controlled data into kernel objects; it only sets handle_rx. There is no OOB write, UAF, or control-flow hijack.
- A:HAvailability impact, high
- With XGMAC_RBUE armed, RBU reasserts until stmmac_rx_refill advances the RX tail; if page_pool_alloc_pages fails, stmmac_napi_poll_rx's napi_complete_done path calls dwxgmac2_enable_dma_irq and the IRQ storms with no forward progress (~695x on Agilex5), livelocking the CPU.