CVE-2026-68309 Fixes MediaTek mt76 Linux Wi-Fi Kernel Crash

The National Vulnerability Database published the record on August 10, 2026, based on information from kernel.org. Its description is concise:

can return

, while

proceeded to dereference the returned pointer while constructing High Efficiency—Wi‑Fi 6—BSS information for the device firmware.

The important operational detail is that this is a kernel availability failure in a hardware-specific Wi‑Fi path, not a remotely exploitable Windows networking bug. A successful trigger would cause the Linux kernel to access address zero through the MediaTek driver, typically producing an oops or panic rather than granting code execution by itself. Neither the NVD entry nor the kernel references identify a proof of concept, an observed attack, a remote trigger, or a privilege boundary crossed.

The crash occurs while Linux programs Wi‑Fi 6 BSS state​

The affected source file is

, part of the shared

component. Linux Kernel Driver Database records show that this component has been present in upstream kernels since Linux 5.12, which explains why the CVE’s upstream affected range begins there.

The vulnerable sequence is straightforward. The driver asks mac80211 for a High Efficiency capability structure that matches the active channel band and virtual-interface type. That lookup is allowed to return no capability. The BSS helper then uses three fields from the returned structure to fill firmware values for 80 MHz, 160 MHz, and 80+80 MHz transmit MCS/NSS capability.

In the uncorrected code, there is no check between obtaining

and reading

. Codebrowser’s copy of the Linux source shows precisely that flow: a capability lookup followed by three unconditional member accesses. The kernel fix adds the missing null handling before those reads can occur.

The immediate effect is prevention of a local kernel crash when the driver enters the relevant BSS-update path with an HE-enabled interface but no matching HE capability object. That is narrower than “any MediaTek Wi‑Fi connection can be crashed.” The code runs as the kernel configures a BSS and sends a

command to the adapter’s firmware; it is not packet parsing code that runs directly on every received wireless frame.

The CVE record’s version range needs careful reading​

Kernel.org’s CVE data lists Linux 5.12 and later as affected in the general upstream history, then identifies fixed release points in maintained stable lines:

• Linux 6.6.148
• Linux 6.12.101
• Linux 6.18.42
• Linux 7.1.6
• Linux 7.2-rc5 and later upstream development builds

Those are the versions administrators should use as minimum upstream baselines. The NVD entry’s machine-readable ranges label those fixed points as unaffected, but that does not mean every arbitrary kernel carrying a lower-looking distribution version is vulnerable. Enterprise distributions routinely backport individual stable fixes without adopting the full upstream version number.

That distinction is especially important for Ubuntu, Debian, Red Hat Enterprise Linux, SUSE Linux Enterprise, Proxmox, OpenWrt, and appliance vendors. A system reporting an older

may already contain the patch, while a custom or vendor-maintained kernel with a newer marketing version may still lack it. Check the vendor changelog or the exact patch backport rather than treating the NVD’s upstream version boundaries as a complete inventory.

There is also a limitation in the record’s broad affected declaration. The CVE correctly identifies a shared library introduced in Linux 5.12, but the practical reach depends on whether the installed kernel enables the relevant

Connac driver and whether the machine actually uses compatible MediaTek wireless silicon. Systems with Intel, Realtek, Qualcomm/Atheros, Broadcom, or USB Wi‑Fi devices using other drivers do not execute this code path.

An earlier mt76 review showed the same assumption elsewhere​

The newly assigned CVE has a longer paper trail than its August 2026 publication date suggests. Linux wireless mailing-list discussion in late 2024 examined the same underlying assumption: that

must always return a valid pointer. An early proposed repair added null checks in HE BSS helpers for the

,

, and

driver paths.

That earlier work matters because it narrows the real lesson from this CVE. This is not evidence of a newly introduced NULL return value in mac80211; the capability lookup’s nullable behavior was already understood during driver review. The present fix addresses a remaining common Connac helper that still consumed the lookup result without validating it.

The original patch discussion also named three relevant MediaTek driver families:

• mt7915, commonly used for MediaTek Wi‑Fi 6 class hardware.
• mt7996, the driver introduced for MediaTek Wi‑Fi 7 hardware.
• mt7925, a newer MediaTek client Wi‑Fi family with per-link BSS handling.

That is useful context, but it should not be turned into a blanket hardware advisory. The final CVE record names the shared Connac MCU file, not a definitive retail-adapter list. Laptop vendors frequently ship MediaTek radios under their own module names, and a PCI ID or

driver binding is more reliable than the brand on the chassis.

Why the fix prevents a panic without proving a network attack​

A null-pointer dereference in kernel code often receives a CVE because it can compromise availability. It does not automatically establish that an untrusted nearby Wi‑Fi client can reach the condition. Here, the source shows the vulnerable call occurs in the driver’s BSS-add routine after the interface’s

state is checked and while the driver is building firmware command data.

The data available on August 11 does not show what combination of interface mode, channel state, capability registration, and user or peer action can make the lookup return

at this point. It also does not say whether the condition is reachable during routine client association, access-point setup, mesh setup, P2P use, a configuration transition, or an error path.

That missing trigger information is why a CVSS score would be premature. NVD explicitly shows CVSS v2, v3, and v4 as unassessed, and it has not mapped the issue to a CWE. The CVE should be patched as a kernel stability and security-maintenance item, but it does not support claims of a Wi‑Fi worm, credential theft, firmware compromise, or remote code execution.

What Windows and Linux administrators should do​

Windows users do not need to remove or replace a MediaTek adapter because of CVE-2026-68309. Windows uses MediaTek’s Windows driver stack, while this CVE names a source file in the Linux kernel’s

driver. WSL 2 also normally uses a virtual network adapter rather than binding directly to the host’s physical Wi‑Fi driver, so a standard Windows-and-WSL installation is not the deployment described by the CVE.

The affected population is Linux installed directly on hardware, Linux-based routers and access points, custom appliances, and dual-boot systems where the Linux installation loads

for a supported MediaTek radio. Administrators should first determine whether the driver is active:

lspci -nnk
lsusb
lsmod | grep '^mt76'
modinfo mt76_connac_lib

If

and a compatible

radio driver are present, apply the latest security kernel from the operating-system vendor and reboot into it. For source-built kernels, use a tree that includes the stable fix corresponding to the maintained branch rather than attempting to infer safety from the kernel’s major version alone.

The practical outcome is clear: patch compatible Linux systems as part of the next kernel maintenance cycle, but do not inflate this into a Windows emergency. CVE-2026-68309 fixes a real kernel dereference in MediaTek’s Wi‑Fi 6-era configuration path; the public record still does not establish an attacker-controlled trigger or impact beyond a potential kernel crash.