CVE-2026-80825

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.