Cloudanix VulnDB

CVE-2026-90382

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

Certain Linux wireless monitoring setups can crash when they receive bad data from the airwaves, causing unexpected system restarts until the software is updated.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Low
Patch risk
None

What it actually does

A bounds check in the mt76x02 RX path correctly discards frames whose MPDU length exceeds the receive buffer, but the surrounding WARN_ON_ONCE triggers kernel taint on every such frame and kernel panic when panic_on_warn is enabled.

Why it matters to the business

Systems using mt76x02 hardware in monitor mode with the fcsfail filter can experience unexpected kernel panics from normal over-the-air corrupted frames, producing unplanned downtime on wireless monitoring or security appliances.

How an attack unfolds

An attacker transmits malformed or corrupted 802.11 frames on a busy channel; when the target device is in monitor mode with fcsfail enabled, the hardware delivers an oversized descriptor, the bounds check fires, and the WARN_ON_ONCE either taints the kernel or panics it.

How to fix it

Apply the upstream fix that removes the WARN_ON_ONCE wrapper around the invalid RX descriptor length check in mt76/mt76x02, allowing silent discard of the frame.

How to confirm the fix worked

Boot the patched kernel, enable the same monitor+fcsfail configuration on an mt76x02 device, inject oversized descriptors, and confirm no WARN or panic occurs while frames are still dropped.

Typical attack path

  1. Place mt76x02 device into monitor mode with fcsfail filter enabled
  2. Transmit corrupted MPDU frames over the air on a busy channel
  3. Hardware delivers descriptor reporting length larger than buffer
  4. Bounds check discards frame but WARN_ON_ONCE executes
  5. Kernel taints or panics if panic_on_warn is set

How to detect it

Search kernel logs and dmesg for WARN_ON_ONCE messages referencing mt76x02 or invalid RX descriptor length; correlate with monitor-mode interface creation and fcsfail filter activation.

  • mt76x02
  • invalid rx descriptor length
  • WARN_ON_ONCE
  • fcsfail

What your security team should do

  • Prioritize kernel update containing the mt76x02 RX descriptor fix on any system that may enter monitor mode
  • Disable panic_on_warn on wireless monitoring hosts until the patch is deployed
  • Avoid enabling the fcsfail filter on mt76x02 hardware in production environments

The record

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.

Affected packages

Ecosystem Package Introduced Fixed