Cloudanix VulnDB

CVE-2026-90370

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A driver bug could let a bad response from wireless hardware freeze the processor during startup, stopping Wi-Fi from working on some devices.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Missing length validation on TLV structures returned by firmware allows a zero-length TLV to cause an infinite loop while walking the response buffer and permits an out-of-bounds u32 read during device probe.

Why it matters to the business

Affected wireless hardware may fail to initialize at boot, leaving systems without Wi-Fi connectivity and potentially causing prolonged CPU usage that impacts overall device availability.

How an attack unfolds

An attacker with the ability to supply a crafted firmware response containing a zero-length TLV during the mt7996 chip configuration probe can trigger an unbounded loop that hangs the CPU; the issue is theoretical because it requires control over the firmware reply path.

How to fix it

Apply the upstream kernel patch that adds checks to reject short fixed fields and to terminate the TLV walk when length would underrun the header or overrun the skb; update to a kernel containing the fix for mt76 mt7996_mcu_get_chip_config.

How to confirm the fix worked

Confirm the patched driver source contains the added length guards before the TLV loop; on running systems, verify that device probe completes without CPU hang when the wireless device is present and that dmesg shows successful mt7996 initialization.

Typical attack path

  1. Device driver initiates chip configuration probe and sends MCU command
  2. Firmware returns a response buffer containing a TLV with len set to zero
  3. Driver loop advances pointer solely by tlv->len without minimum-size check
  4. Pointer never advances, loop spins indefinitely and consumes CPU
  5. Device probe hangs, preventing normal Wi-Fi operation

How to detect it

Review kernel logs for repeated mt7996_mcu_get_chip_config entries without completion, watchdog timeouts, or soft lockup messages during early boot on mt7996 hardware; no post-exploitation artifacts are expected because the condition occurs only during probe.

What your security team should do

  • Prioritize kernel updates on systems using mt7996 hardware
  • Monitor upstream mt76 commits for the exact TLV bounds patch
  • Test device probe behavior after update in lab hardware
  • Document affected firmware versions and schedule staged rollouts

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config The response TLV loop advanced by tlv->len without a minimum, so a theoretical firmware response containing a zero-length TLV could spin forever, hanging the CPU during device probe. The u32 payload was also read without bounds checking. Reject a short fixed field, stop on a TLV whose length underruns the header or overruns the skb.

Affected packages

Ecosystem Package Introduced Fixed