CVE-2026-68197: Upstream Fixes Marvell Wi-Fi TDLS Crash

The patch was posted by Doruk Tan Ozturk to the Linux wireless mailing list on July 16 and subsequently merged into the wireless tree as commit

. LWN.net lists it in Linux 7.2-rc5, confirming it has reached the upstream release-candidate stream. The submitted NVD page was inaccessible when this advisory was published, returning a 502 Bad Gateway error, so NVD’s own CVSS score, affected-version range, and CPE inventory could not be independently checked.

For Windows users, the immediate point is straightforward: this is not a Windows Wi‑Fi driver vulnerability. It affects Linux systems that load the upstream

module, including dual-boot PCs, embedded devices, and Linux deployments using supported Marvell hardware. Standard WSL 2 installations are not the usual exposure path because WSL uses a virtualized network adapter rather than handing the physical Wi‑Fi device and its Linux driver directly to the guest.

The crash sits in the TDLS setup path​

The vulnerable function,

, prepares an HT Operation information element while the driver is building a TDLS frame. TDLS, short for Tunneled Direct Link Setup, allows two Wi‑Fi clients on the same access point to set up a direct link instead of relaying all traffic through the access point.

In the affected code, the driver first checked whether the current access point’s beacon supplied an HT Capabilities element. It then used a separate pointer,

, to read the AP’s HT Operation information without confirming that second pointer existed.

Those two beacon elements are parsed and stored independently. An AP can therefore leave the driver with this state:

• The HT Capabilities information is present, so bcn_ht_cap is valid.
• The HT Operation information is absent, so bcn_ht_oper remains null.
• A TDLS setup attempt reaches the bandwidth-following code and dereferences bcn_ht_oper.

That final operation causes the kernel fault. The mailing-list patch describes the trigger as a TDLS link setup with a peer while already associated with such an AP; it does not claim code execution, privilege escalation, credential disclosure, or a bypass of Wi‑Fi encryption. The demonstrated impact is availability: the system can crash or become unusable until it recovers.

The repair is unusually small, changing a single condition so the driver checks

—the pointer it actually dereferences—rather than merely checking

. That is the correct narrow fix, and reviewer Francesco Dolcini marked the patch as reviewed on July 20.

Why the trigger is narrower than a rogue Wi‑Fi hotspot crash​

A hostile or badly implemented access point is only part of the condition. The

device must also use the TDLS path, have the relevant 40 MHz HT-channel-width capability, and attempt to set up a peer link. Simply seeing a malformed beacon is not enough by itself according to the upstream bug report.

That makes this a materially different class of Wi‑Fi issue from a bug reachable just by scanning for networks or associating to an AP. It should still be treated as a security issue because an attacker who controls an AP, or can impersonate one in an appropriate radio environment, can supply crafted management information. But the record presently supports a kernel denial-of-service assessment, not the much broader claims sometimes attached to “remote Wi‑Fi CVE” headlines.

There is another practical limitation: TDLS is far less common in managed enterprise WLANs than ordinary client-to-AP traffic. Many organizations disable it at the WLAN policy level, and many home users never invoke it. That reduces routine exposure, but it does not remove the bug from Linux machines whose

driver and TDLS support are active.

The fact that every other use of

in the driver already checked the pointer is significant. This was not a complicated memory-management failure spread across asynchronous callbacks. It was an isolated validation mistake in a specialized frame-construction path, which explains both the tiny patch and the sharply defined trigger.

The affected driver is for specific Marvell hardware​

The Linux Wireless documentation identifies

as the FullMAC driver for Marvell 802.11n hardware attached through SDIO, PCI Express, or USB. Listed families include SD8786, SD8787, SD8797, SD8897, PCIe 8766 and 8897 devices, and USB 8797 hardware.

That hardware scope matters more than the CVE’s generic “Wi‑Fi” label. Most Linux desktops and laptops use Intel, MediaTek, Qualcomm Atheros, Realtek, or Broadcom drivers, not

. Administrators should not assume every Linux wireless interface is affected, nor should they dismiss the issue solely because Marvell has largely disappeared from recent mainstream PC designs. These chipsets remain present in older tablets and laptops, industrial systems, development boards, appliances, and some embedded products.

A useful first check on a Linux installation is whether the module is loaded:

Systems using PCIe hardware commonly show

; SDIO and USB implementations may use

or

. Hardware inventory from

,

, or

can then establish whether the driver is attached to an active device rather than merely present in the installed kernel package.

Do not confuse a Windows Device Manager entry for a Marvell adapter with Linux driver exposure. A Windows installation uses its own Windows driver stack. The vulnerable source file is Linux kernel code under

; it does not establish that a Windows Marvell driver has the same defect.

Upstream has the fix; distribution status remains the operational question​

The patch carries a

tag, which signals that the maintainer believes it is appropriate for stable-kernel backporting. That tag is important, but it is not proof that a given distribution has shipped the repair. Stable requests can be accepted, delayed, rejected because of conflicts, or incorporated by distributors on their own schedules.

As of August 11, the independently verifiable upstream position is that the fix is in the Linux wireless tree and appears in Linux 7.2-rc5. The available record does not establish a released stable-kernel version containing the fix, nor does it establish package versions for Ubuntu, Debian, Fedora, RHEL, SUSE, Android-derived kernels, or device-vendor BSPs.

That gap is especially relevant for embedded deployments. Vendors often freeze a long-term kernel and selectively backport fixes, so

alone may be misleading. A system on an old-looking vendor kernel might already include the one-line correction; a system on a newer version number might not, depending on its source base and maintenance process.

Administrators should therefore ask their kernel vendor or distribution whether its

package includes the upstream fix associated with CVE-2026-68197 or commit

. Checking only for a future Linux 7.2 package is too blunt an approach when a targeted backport may arrive first.

Windows and WSL users should avoid the wrong remediation​

Microsoft’s WSL documentation says WSL 2 uses a virtualized Ethernet adapter and, in its normal NAT configuration, a separate virtual network interface. Even mirrored networking changes WSL’s networking architecture rather than making the Linux guest responsible for the physical Windows Wi‑Fi adapter through the upstream Marvell driver.

As a result, a Windows 11 user running Ubuntu in ordinary WSL 2 should not treat this CVE as a reason to update a Windows Marvell wireless driver, replace a Wi‑Fi adapter, or disable their host’s wireless connection. The relevant remediation belongs with the Linux kernel running on hardware that loads

.

The exception is not mainstream WSL but unusual infrastructure: a full Linux virtual machine with a passed-through wireless device, a custom Linux appliance hosted on Windows hardware, or a dual-boot installation that boots directly into Linux. In those cases, the guest or alternate OS can own the physical device and load the affected driver.

For fleet teams, the most sensible response is to identify Linux hosts with active

modules, confirm whether TDLS is enabled or used in their environment, and consume the vendor kernel update once available. The upstream fix is a one-line null check, but until that check reaches the kernel actually booted on an affected Marvell device, a malformed AP beacon combined with TDLS setup can still turn a wireless association into a kernel crash.