CVE-2026-68195 Fixes MT7663 USB/SDIO Wi-Fi Crashes

The NVD record, sourced from kernel.org and published to NVD on August 10, identifies the affected file as

. Upstream Linux commit

, authored by Devin Wittmayer and accepted by mt76 maintainer Felix Fietkau, makes a narrowly targeted six-line change: it discards

events when the hardware is not connected through MMIO.

For administrators, the immediate action is to update to a distribution kernel containing the fix, rather than attempting to disable a broad class of MediaTek Wi-Fi hardware. NVD identifies fixed upstream stable releases as Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6, with the patch also present in Linux 7.2-rc5. Distribution kernels may carry the patch under different package and build numbers because vendors routinely backport stable fixes.

The crash sits in a transport mismatch​

is a transmit/receive notification event intended for the MMIO version of the mt76 driver. Before the fix, two receive-side functions —

and

— passed that event to

regardless of whether the adapter used the MMIO, USB, or SDIO transport.

That eventually leads to

, which invokes the transport’s

callback. MMIO queue operations provide that callback. The USB and SDIO implementations used by the affected MT7663 paths do not, leaving the function pointer as

.

The result is unusually straightforward for a kernel CVE: if the wrong notification reaches the receive worker on an affected non-MMIO device, the driver tries to call a function that does not exist. The expected outcome is a kernel oops or system crash, and potentially a wireless interface reset or loss of connectivity depending on how the distribution and watchdog configuration handle the fault.

The upstream change does not introduce a new cleanup routine for USB and SDIO. It prevents the event from reaching the MMIO-specific cleanup path in the first place. In the raw receive-check path, the driver returns before calling

; in the queued socket-buffer path, it frees the received buffer and exits the switch case. The repair is appropriately small because the event is not meaningful on those transports.

MT7663 USB and SDIO systems are the real scope​

The CVE description is easy to misread because the affected source file lives under the

driver directory. The primary record is more specific: it calls out “mt7663 USB and SDIO buses” as the configurations where

is absent. The original regression was introduced with support for mt7663u, the USB variant, in the commit identified by upstream as the fix’s origin point.

That distinction rules out the most alarming interpretation of the advisory. This is not evidence that every computer with a MediaTek mt76-supported Wi-Fi card is exposed to a remotely exploitable kernel vulnerability. It is a transport-specific driver correctness bug affecting the path used by certain MT7663 USB and SDIO devices.

A system with a MediaTek adapter attached over PCIe may still use the broad mt76 driver family, but the cited NULL callback condition is absent when that device uses the MMIO queue operations. Conversely, embedded Linux deployments deserve more attention than a generic desktop inventory might suggest. USB and SDIO are common attachment methods in compact boards, router-class appliances, development kits, and integrated wireless designs where the Wi-Fi subsystem is not presented as a conventional PCIe endpoint.

The CVE record also says the same design error was corrected in related mt7921 and mt7925 patches in the same series. That context is useful, but it should not be stretched into an affected-product claim for this CVE. CVE-2026-68195 tracks the mt7615/MT7663 path and the commits listed in its own record; separate driver fixes need to be tracked under their own advisories and distribution updates.

NVD has not assigned severity or an attack vector​

As of August 11, NVD lists no CVSS v4, CVSS v3, or CVSS v2 score for CVE-2026-68195. It also provides no CWE classification and no NVD-enriched attack vector. The record describes the fault mechanism but does not say an attacker can reliably cause a vulnerable wireless device to emit the event, whether it requires malformed traffic, firmware behavior, local access, a particular power-management transition, or some other trigger.

That omission has operational consequences. Teams should treat this as a kernel stability and security-maintenance issue for the affected hardware, but should not assign it an invented “critical” rating simply because the failure occurs in kernel context. A NULL function-pointer dereference is serious when it can be reached, yet the public record currently establishes the crash condition rather than a demonstrated exploitation chain.

There is also no claim of active exploitation, proof-of-concept code, information disclosure, privilege escalation, or code execution in the NVD entry or the upstream patch. The right description today is a potential kernel denial-of-service condition in a narrowly defined MediaTek Wi-Fi transport path, not a confirmed remote takeover flaw.

The version record requires careful reading​

The NVD configuration data marks Linux 5.8 as the first affected release, then identifies fixed points for active stable branches. That does not mean every release numerically later than 5.8 is automatically safe. It means the issue entered the codebase in the Linux 5.8 era and is remediated in the listed maintained branches after the relevant backports landed.

The practical fixed-version map is:

• Linux 6.6 users should be at 6.6.148 or a vendor kernel that includes the equivalent backport.
• Linux 6.12 users should be at 6.12.101 or a vendor kernel that includes the equivalent backport.
• Linux 6.18 users should be at 6.18.42 or a vendor kernel that includes the equivalent backport.
• Linux 7.1 users should be at 7.1.6 or a vendor kernel that includes the equivalent backport.
• Linux 7.2-rc5 includes the upstream fix for testing and development users.

A

check alone can be misleading on enterprise distributions. Red Hat Enterprise Linux, Ubuntu LTS, SUSE Linux Enterprise, Debian stable derivatives, appliance vendors, and board-support-package providers often retain an older-looking base version while applying selected stable patches. Administrators should check the vendor’s kernel changelog, security advisory, or source package patch set for the upstream commit or its equivalent rather than concluding that a kernel is vulnerable solely from its apparent major and minor version.

Systems running an unmaintained kernel line between Linux 5.8 and the presently maintained branches need a separate review. The upstream fix is small enough to backport, but local backporting should preserve both guards: one in

and one in

. Applying only one would leave a second receive path able to reach the invalid callback.

Windows systems are largely outside this CVE’s direct scope​

CVE-2026-68195 is a Linux kernel driver issue, not a Windows Wi-Fi driver advisory. A Windows 10 or Windows 11 machine using the vendor’s native MediaTek driver does not execute

, so this CVE is not a reason to deploy a Windows cumulative update or replace a normal Windows wireless driver.

The relevant Windows-adjacent population is IT staff who manage Linux hosts, embedded Linux images, routers, or appliances from Windows desktops, as well as developers building Linux kernels and device images. Those environments should identify MT7663 USB and SDIO hardware, confirm the kernel package’s patch level, and prioritize the update where Wi-Fi availability is operationally important.

The patch has already reached the upstream stable releases NVD names. The remaining work is down the distribution chain: vendors need to ship it, and administrators need to verify that their particular appliance or board image has consumed it before a malformed or unexpected driver event becomes a repeatable wireless crash.