CVE-2026-68195
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A wireless driver bug could cause certain Linux computers to crash when using USB or SDIO Wi-Fi adapters, requiring a reboot to recover.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
NULL pointer dereference in mt7615_rx_check and mt7615_queue_rx_skb when PKT_TYPE_TXRX_NOTIFY is dispatched to mt7615_mac_tx_free on USB/SDIO buses; the mmio-only tx_cleanup callback is NULL, causing a crash in the RX worker.
Why it matters to the business
Kernel panic or denial of service on systems using mt7615/mt7663 wireless hardware over USB or SDIO, leading to loss of network connectivity and potential system instability until reboot.
How an attack unfolds
An attacker with the ability to inject or trigger wireless RX events of type TXRX_NOTIFY on a vulnerable non-mmio bus causes the RX worker to follow the NULL function pointer during DMA cleanup, resulting in an immediate kernel fault.
How to fix it
Apply the upstream kernel patch that adds an mt76_is_mmio guard before dispatching TXRX_NOTIFY events; rebuild and deploy the updated kernel image on all affected systems.
How to confirm the fix worked
Confirm the mt76 driver source contains the mt76_is_mmio guard around TXRX_NOTIFY handling in mt7615_rx_check and mt7615_queue_rx_skb; test that USB/SDIO devices no longer crash when receiving the event type.
Typical attack path
- Gain proximity or control sufficient to deliver crafted 802.11 frames to the mt76 device
- Trigger reception of a PKT_TYPE_TXRX_NOTIFY event on USB or SDIO transport
- mt76_is_mmio check is absent so the event reaches mt7615_mac_tx_free
- queue_ops->tx_cleanup is invoked through the NULL pointer
- Kernel oops and potential system crash or reboot
How to detect it
Inspect kernel logs for oops or NULL pointer dereference traces mentioning mt7615_mac_tx_free, mt76_queue_tx_cleanup, or queue_ops->tx_cleanup during RX worker activity on mt76 devices.
What your security team should do
- Prioritize kernel updates for any hosts exposing mt76 USB or SDIO wireless interfaces
- Monitor vendor firmware releases that back-port the mmio guard
- Temporarily disable affected wireless hardware if updates cannot be applied promptly
The record
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices").
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|