CVE-2026-90382 in Linux
Summary
by MITRE • 09/17/2026
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 WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set.
Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf ("mt76x2: remove some harmless WARN_ONs 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel's mt76 wireless driver subsystem, specifically affecting the mt76x02 component, stems from improper handling of invalid receive descriptors when operating under specific monitoring conditions. This issue is particularly relevant for devices utilizing the MT7612U chipset or similar hardware architectures that support monitor mode with frame check sequence failure filtering enabled. In this operational state, the wireless interface captures all frames on a channel, including those corrupted by noise or interference. The core technical flaw lies in how the driver processes these incoming data units. When a frame is received, the hardware populates an rx descriptor which includes metadata such as the MPDU length derived directly from the physical layer information of the captured packet. Under normal circumstances, this length value corresponds to valid data structures within the allocated receive buffer. However, when dealing with corrupted frames in monitor mode, the reported length can exceed the actual size of the received buffer because the hardware reports the intended or nominal frame length rather than accounting for truncation due to corruption.
The existing code implementation includes a bounds check designed to prevent out-of-bounds memory access by verifying that the descriptor's length does not surpass the available buffer space. While this logic correctly prevents immediate exploitation via memory corruption, it is wrapped in a WARN_ON_ONCE macro intended for debugging purposes during development. This design choice introduces a significant stability risk in production environments. The presence of over-the-air garbage frames on busy wireless channels triggers this warning condition frequently. Although the frame is discarded safely, the invocation of WARN_ON_ONCE generates kernel warnings that can be interpreted as critical errors depending on system configuration. Specifically, if the kernel parameter panic_on_warn is enabled, which is common in hardened or enterprise Linux distributions to ensure immediate visibility of potential issues, a single instance of this condition will cause an instantaneous kernel panic and subsequent system reboot. This transforms what should be a benign network noise event into a denial-of-service vector capable of destabilizing the host machine without any malicious interaction beyond mere presence on the airwaves.
From a security architecture perspective, this vulnerability aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions and CWE-20: Improper Input Validation in terms of handling unexpected data states gracefully. The failure to handle invalid input lengths silently rather than triggering high-severity diagnostic routines represents a lack of robustness against environmental noise. Furthermore, the ability to induce a system crash through passive observation of wireless traffic relates to availability impacts often categorized under MITRE ATT&CK techniques involving resource exhaustion or denial-of-service via network-based triggers. The attacker does not need to inject malicious payloads; simply being within range and transmitting on the same channel as the vulnerable device is sufficient to trigger the condition if the environment contains typical levels of RF interference that result in corrupted frames with inflated length descriptors.
The resolution involves removing the WARN_ON_ONCE wrapper from the bounds check logic, thereby allowing the driver to silently discard invalid frames without generating kernel warnings or triggering panic conditions. This approach mirrors previous remediation efforts within the same subsystem where harmless warnings were removed from transmit and receive status paths to improve stability. By treating these hardware-reported anomalies as expected occurrences in monitor mode rather than exceptional errors, the system maintains operational continuity even under heavy RF noise. Mitigation strategies for administrators include applying this kernel patch or updating to a version of the Linux kernel that includes this fix. For environments where immediate updates are not feasible, disabling fcsfail filter modes if they are strictly necessary can reduce exposure, though this may impact monitoring capabilities. Ultimately, ensuring that wireless drivers handle hardware-reported inconsistencies with graceful degradation rather than fatal error handling is critical for maintaining availability in noisy RF environments.