CVE-2026-90382: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length
The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARNONONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when paniconwarn is set.
Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf ("mt76x2: remove some harmless WARNONs in tx status and rx path") did for the neighboring rx and tx status paths.
Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.
Event History
Frequently Asked Questions
Which systems are exposed to a panic from this issue?
Systems using the mt76x02 receive path are exposed when operating in monitor mode with the fcsfail filter enabled and panic_on_warn set. The issue was observed with an MT7612U on a busy channel.
What is required to trigger the problem?
The hardware must pass a corrupted frame whose reported MPDU length exceeds the received buffer length. Such over-the-air corrupted traffic can cause the receive bounds check to issue a WARN_ON_ONCE, which taints the kernel or panics it when panic_on_warn is enabled.
What can be done before the fix is deployed?
Avoid using monitor mode with the fcsfail filter enabled on affected hardware, particularly where panic_on_warn is set. This removes the condition in which corrupted frames are passed up and can trigger the warning.
How can I tell whether this has occurred?
A malformed received frame causes the kernel to be tainted by the WARN_ON_ONCE condition. On systems with panic_on_warn enabled, the first occurrence can instead result in a kernel panic.