CVE-2026-80825 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925: ensure tx headroom in usb_sdio_tx_prepare_skb
mt7925_usb_sdio_tx_prepare_skb() pushes a TX descriptor and a USB header onto every skb and assumes the headroom for them is already there. That holds for locally generated traffic, where mac80211 reserves hw->extra_tx_headroom, but forwarded frames are sent through ieee80211_8023_xmit(), which does not reserve it. Bridge a wired interface to an mt7925u AP and the first forwarded frame that arrives short panics the kernel:
skbuff: skb_under_panic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1 kernel BUG at net/core/skbuff.c:212! Call trace: skb_panic+0x58/0x60 (P) skb_push+0x58/0x60 mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common]
mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb]
__mt76_tx_queue_skb+0x54/0xe8 [mt76]
mt76_txq_schedule.part.0+0x204/0x478 [mt76]
mt76_txq_schedule_all+0x50/0x80 [mt76]
mt792x_tx_worker+0x68/0x100 [mt792x_lib]
__mt76_worker_fn+0x84/0x150 [mt76]
Whether a given setup hits it depends on how much headroom the ingress netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging onboard ethernet to a Netgear A9000; originally reported on an MT7986 router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet), which leaves more headroom, helped narrow the trigger to the ingress path.
The same bug was fixed on mt7921 by commit 98c4d0abf5c4 ("mt76: mt7921: don't assume adequate headroom for SDIO headers"), but mt7925 was copied from mt7921 without the fix. Add the same guard here.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in the Linux kernel's MediaTek MT7925 wireless driver represents a critical memory management flaw within the network stack, specifically affecting how transmitted data buffers are prepared for USB and SDIO interfaces. The core issue resides in the mt7925_usb_sdio_tx_prepare_skb function, which is responsible for preparing sk_buff structures before transmission. This routine unconditionally pushes a TX descriptor and a USB header onto each socket buffer without verifying that sufficient headroom exists within the buffer's memory layout. In network programming, headroom refers to reserved space at the beginning of a data buffer intended for protocol headers added during processing. The driver assumes this space is always available, an assumption that holds true for locally generated traffic where the mac80211 subsystem explicitly reserves hardware-specific extra transmission headroom via hw->extra_tx_headroom. However, this safety mechanism does not apply to frames being forwarded from other network interfaces.
When a wired interface is bridged to an MT7925-based access point, incoming Ethernet frames are processed through the ieee80211_8023_xmit function rather than the standard local transmission path. This forwarding path does not reserve the necessary extra headroom required by the mt76 driver family for its specific hardware descriptors and headers. Consequently, when the first forwarded frame arrives at a bridge configuration, the driver attempts to write protocol headers into memory locations that are already occupied or outside the allocated buffer boundaries. This results in an out-of-bounds write operation, triggering a kernel panic known as skb_under_panic. The error manifests immediately upon transmission of such frames, causing a denial of service by crashing the entire operating system rather than merely dropping the packet.
The operational impact of this vulnerability is severe due to its potential for remote or local exploitation depending on network topology. An attacker with access to the bridged wired interface can trigger the kernel panic simply by sending standard Ethernet traffic across the bridge, effectively causing a complete system crash without requiring elevated privileges or complex payload construction. This makes the flaw particularly dangerous in router and gateway deployments where automatic bridging of LAN ports is common. The vulnerability was originally observed on MT7986 routers running OpenWrt but has been confirmed to affect mt7925 devices such as those found in Netgear A9000 access points when connected via USB or SDIO interfaces. Testing indicates that the likelihood of triggering the bug depends heavily on how much headroom the ingress network device leaves in its receive sk_buffs, with some hardware configurations like Raspberry Pi 4 using bcmgenet providing enough default space to mask the issue temporarily, while others like Raspberry Pi 5 expose it immediately.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input and CWE-787 Out-of-bounds Write, as the driver writes data beyond the allocated buffer limits due to insufficient space allocation checks. In terms of attack vectors, it relates to ATT&CK technique T1499 Endpoint Denial of Service, where an adversary disrupts availability by causing a system crash through resource exhaustion or memory corruption. Although this specific instance is triggered via legitimate network traffic rather than malicious exploitation code, the underlying mechanism remains a classic buffer overflow scenario resulting from improper input validation and state assumption within kernel-space drivers.
The resolution involves implementing explicit headroom checks similar to those applied in the mt7921 driver variant by commit 98c4d0abf5c4. The fix ensures that if insufficient headroom is detected, the system allocates additional space or adjusts the buffer pointer appropriately before pushing headers. This prevents the out-of-bounds write and stabilizes the transmission path for bridged traffic. To mitigate this risk in environments where patching may be delayed, administrators should avoid bridging wired interfaces directly to MT7925-based wireless access points unless the ingress network devices are known to provide sufficient default headroom. However, relying on hardware-specific buffer characteristics is not a robust security practice; applying the kernel update that includes the corrected mt76 driver logic remains the only definitive remediation strategy. This incident highlights the importance of rigorous code review when porting fixes between similar driver variants, as oversight in copying patches can leave critical vulnerabilities exposed even after they have been resolved elsewhere in the same subsystem.