CVE-2026-68310: Update Linux Kernel to Stop MT7915 Crashes

The NVD entry, published August 10, attributes the issue to kernel.org and points to five stable-tree backports. It does not assign a CVSS score, CWE, exploit status, or a known exploitation indication. That absence is meaningful: this is a reliability and local attack-surface fix, not evidence of a remotely exploitable Wi‑Fi takeover.

Windows itself is not affected by this Linux kernel driver flaw. Windows users should care only where they operate Linux directly: a Linux router, an access point, a NAS, a hypervisor host, a dual-boot installation, or another appliance using the in-kernel

driver with MediaTek MT7915 hardware. A standard Windows 11 installation does not load Linux’s

.

The fault is in capability selection, not radio firmware​

The vulnerable code sits in the

portion of the upstream

driver, Linux’s driver family for several MediaTek wireless chipsets. MT7915 hardware is commonly used in Wi‑Fi 6-capable embedded networking equipment, where the Linux host driver packages configuration commands for the wireless device firmware.

Two functions were at issue:

and

. Each works with HE capabilities while building TLVs—type-length-value data records—sent through the driver’s microcontroller command path. One configures HE information for the basic service set; the other configures HE beamforming details for a station.

The defect was straightforward but consequential. The code checked whether HE support was generally enabled, then called

to obtain the specific HE physical-layer capability entry appropriate to the virtual interface type. That helper can return

if no entry matches the interface’s type. The old path dereferenced the return value anyway.

A kernel NULL dereference normally means an oops or panic rather than a clean feature failure. On a desktop, that can mean a lost Wi‑Fi connection or a kernel crash. On an appliance that is itself acting as the network edge, the same failure can turn a configuration change, interface transition, or station setup event into an outage requiring watchdog recovery or manual intervention.

The distinction matters operationally: this CVE does not describe malformed over-the-air frames corrupting memory, an arbitrary-code-execution primitive, or a MediaTek firmware update requirement. It addresses an unchecked result in Linux driver code.

The fix deliberately omits HE setup when no record exists​

The kernel patch changes the order of operations. It retrieves the HE capability before allocating and appending the HE-specific TLV; if no capability record is available for that virtual interface, the function returns without adding that HE configuration.

The beamforming path receives the same treatment. Before it constructs a

record for an HE-capable station using explicit beamforming, the patched code retrieves the virtual interface’s capability and stops if it cannot find one. The helper that fills in HE beamforming data is then passed the already-validated capability pointer instead of doing its own unchecked lookup.

That implementation detail reveals the vendor-maintainer assessment of the proper failure mode. The safe response is not to synthesize a generic HE capability or force a capability from a different interface type. The driver simply declines the HE-specific programming that it cannot safely describe.

A 2024 patch discussion archived by Patchew and the Linux kernel mailing lists had already identified the same underlying

behavior: the helper could return

, leading to a NULL-pointer dereference. The discussion named the MT7915 code introduced by commit

as one of the affected paths. The newly published CVE narrows its scope to the MT7915 handling and records the stable fixes now available.

That history is more than trivia. It indicates this was not a newly discovered radio-protocol weakness. The bug was known in the upstream development process, fixed in code, and later assigned a CVE as the fix propagated into maintained kernel branches.

Version numbers are more useful than the CVE’s broad “affected” marker​

The NVD record lists Linux kernel 5.18 as the first affected release and identifies the vulnerable source file as

. It also marks releases before 5.18 as unaffected and records fixed points for four maintained stable series: 6.6.148, 6.12.101, 6.18.42, and 7.1.6.

For administrators, the practical reading is:

• Linux systems on a kernel older than 5.18 are outside the affected range identified by the CVE record.
• Systems on the named stable branches should be considered remediated only at or above the specified fixed release for that branch.
• A distribution kernel can be safe while retaining an older-looking version string if its maintainer backported one of the listed stable commits.
• A newer kernel is not automatically safe if it is a vendor fork that omitted the relevant upstream or stable-tree patch.

The CVE record also lists five stable commit IDs rather than a single universal patch. That is normal for kernel vulnerabilities fixed across multiple supported branches, but it creates a common inventory trap: scanning only for the original upstream commit can incorrectly flag a system that has received an equivalent stable backport.

The reverse mistake is more serious. Seeing a major version such as 6.6 or 6.12 and assuming the issue is resolved ignores the point-release boundary. The stable releases named in the record are the relevant threshold, not the branch number alone.

Exposure depends on both the driver and the deployment​

This is a narrow vulnerability in a specific MediaTek driver, not a general Linux Wi‑Fi flaw. A Linux system that does not use the

driver is not affected. Systems using an Intel

, Qualcomm

, Realtek, Broadcom, USB, or Ethernet adapter may be exposed to unrelated bugs, but CVE-2026-68310 does not apply to them.

Even among systems with MT7915-based hardware, the failing condition is specific: HE support has to be relevant to the operation, while

finds no matching capability entry for the virtual interface type. The original code path is involved in BSS configuration and station beamforming setup, which makes access points, routers, and systems using multiple interface modes more relevant than a simple laptop Wi‑Fi client.

The public record does not say that a nearby Wi‑Fi client can reliably trigger the bug merely by joining a network, sending management frames, or advertising chosen HE capabilities. It also does not document an exploit, affected commercial device list, or a required device-firmware version. Administrators should not turn that lack of detail into a claim of zero risk, but they should not treat the CVE as an active remote compromise advisory either.

For managed environments, the risk is best understood as disruption potential where an unpatched MT7915 Linux device performs wireless interface and station configuration under conditions an operator—or, depending on the appliance’s controls, a local or authenticated user—can influence.

Patch the kernel, then verify the driver actually in use​

Kernel updates are the correct remediation. There is no separate application package named for this CVE, and the fix is in the kernel driver source rather than a userspace Wi‑Fi utility.

On a Linux host, administrators can first establish whether the relevant driver is loaded with

or inspect the kernel log for

and

initialization messages. On embedded devices, the more reliable route is usually the vendor’s hardware specification, support portal, or package manifest; many products identify the radio chipset without exposing a conventional desktop-style module inventory.

Then confirm the actual running kernel with

, while checking the distribution or appliance vendor’s advisory for backported patches. Red Hat, SUSE, Canonical, Debian, OpenWrt-derived appliance vendors, NAS suppliers, and router vendors can all package security fixes independently of their visible base version.

Organizations that build custom kernels should apply the stable backport appropriate to their codebase, rather than copying only part of the change. The BSS HE path and the station beamforming path are both part of CVE-2026-68310. Patching one NULL check while leaving the other code path intact would not match the remediation documented in the kernel record.

The central operational consequence is modest but real: an unpatched Linux system using the MT7915 driver can fail while preparing Wi‑Fi 6 configuration for an interface configuration it cannot represent. Updating to the fixed kernel releases turns that edge case into a skipped HE-specific setup operation instead of a kernel dereference.