CVE-2026-68326: Patch Linux Marvell AP Wi-Fi Driver Flaw

The CVE record reached the NVD dataset on August 10, 2026, with the NVD page showing no CVSS v3 or v4 assessment as of August 11. The underlying fix was posted to the Linux wireless mailing list by HE WEI in late June and subsequently landed in the wireless tree before being backported to the currently maintained stable branches. No public exploitation has been reported.

For Windows users, the distinction is straightforward: this is a Linux kernel driver vulnerability, not a flaw in Windows’ native Wi‑Fi stack. A typical WSL2 installation also will not be using a physical Marvell adapter through

; WSL networking is virtualized. The systems worth checking are Linux-based appliances, embedded systems, single-board computers, routers, test rigs, and laptops that use affected Marvell/NXP-era wireless hardware as a hotspot.

The vulnerable path is an AP association event​

The affected code lives in

, in the handler for

. This is the event the firmware sends when a client associates or reassociates with a wireless interface operating as an access point.

Linux Wireless documentation identifies

as the FullMAC driver for certain Marvell 802.11n SDIO, PCIe, and USB devices, including SD8786, SD8787, SD8797, SD8897, PCIe 8766/8897, and USB8797 hardware. The same documentation lists AP capability for the driver. In practical terms, the vulnerable path is not exercised by a machine merely connecting to a normal Wi‑Fi network as a client; it is reached when the adapter is hosting one.

The bug was in the driver’s handling of association-request Information Elements, or IEs. Firmware provides a length field for the association event, and the driver used that value to calculate the length of the IE region. Before the fix, it trusted the firmware-supplied length without checking that it was at least as large as the event header and no larger than the fixed

storage where the event had been copied.

That leaves two bad cases. A claimed event length that is too short causes an unchecked subtraction to go negative, then become a huge unsigned length. A claimed length that is too large causes later code to treat bytes beyond

as valid IEs.

The consequence is an out-of-bounds read, not a demonstrated takeover​

NVD’s description records a KASAN-detected slab out-of-bounds read in

. On the AP 802.11n path,

parses the association IEs to determine a newly associated station’s capabilities. If the supplied length extends beyond the actual event buffer, the generic cfg80211 parser can dereference element headers outside the

allocation.

The same bogus length is also passed to

. NVD notes that a less extreme overstatement can result in stale bytes from the fixed event buffer being copied into an

notification. That is an information-exposure concern for local consumers of netlink wireless events, separate from the more obvious kernel out-of-bounds read.

The important operational conclusion is that this is a device-firmware trust-boundary flaw. It is not documented as a case where any nearby Wi‑Fi client can simply send a malicious association frame and directly choose

; that field is generated by the Marvell device firmware. The CVE explicitly identifies a malicious or malfunctioning

device as the source of the bad event. A hostile client may trigger association activity against an AP, but the public record does not establish direct remote control of the firmware-reported length through an over-the-air management frame.

That sharply limits the conventional remote attack narrative, but it does not make the fix optional for systems that use this hardware in AP mode. FullMAC drivers necessarily accept high-level event structures from firmware. The patch closes a place where the host kernel accepted a firmware claim that did not match the bounds of its own storage.

The patch checks the right boundary for all three transports​

The upstream patch adds a validation step immediately after the driver finds the start of the association IE data. It rejects an event when the firmware’s length falls before the event header or when the reported endpoint lies beyond

.

That choice deserves attention because it avoids a common but incorrect fix: checking only a transport packet length. The CVE description explains that USB and SDIO retain a four-byte event header in

, while PCIe removes it with

. The layout seen by the transport layer therefore differs. By contrast, every transport copies the event into the same

buffer before this handler uses it.

The resulting check is transport-neutral. It protects SDIO, USB, and PCIe implementations without assuming that all three expose the same received-frame layout. The patch also frees the pending station-information structure and aborts processing when it sees an invalid length, preventing the untrusted value from reaching either the IE parser or the new-station notification path.

This is also not the first bounds issue in this driver family. The patch description connects CVE-2026-68326 to a 2023

receive-path fix, commit

, which addressed an out-of-bounds access and integer underflow involving received packets. The older correction hardened packet reception; this one covers the AP event route. The recurring pattern is firmware-provided length metadata being treated as inherently reliable when it must be bounded before it controls pointer arithmetic.

Fixed releases are more useful than the broad affected range​

The CVE record says code from Linux 3.5 onward is affected, because that is when the AP event handling framework was introduced. That statement is technically correct but insufficient for patch management. The relevant remediation line is the stable release mapping:

• Linux 6.6 is fixed in 6.6.148.
• Linux 6.12 is fixed in 6.12.101.
• Linux 6.18 is fixed in 6.18.42.
• Linux 7.1 is fixed in 7.1.6.
• Mainline incorporated the change in Linux 7.2-rc5.

Administrators should not assume that a distribution’s kernel package is vulnerable or fixed strictly from the upstream version string. Enterprise and long-term-support distributions routinely backport individual patches while retaining an older-looking base version. Check the distribution’s security advisory or its kernel changelog for CVE-2026-68326 or the

uAP association-event fix.

The NVD entry lists five stable commit references, consistent with backports across those maintenance lines. It does not list a CWE classification, vendor severity rating, exploit status, or an NVD-generated CVSS score yet. Those omissions should not be filled in with assumptions: the technical effect is clear, while an official severity assessment is still absent.

Who should act now​

The priority group is small but identifiable: systems using

,

, or

with one of the supported Marvell chipsets and configured to run an AP through

, NetworkManager, an embedded management stack, or another uAP workflow.

A quick inventory starts with loaded modules and interface capabilities:

lsmod | grep mwifiex
lspci -nn | grep -i marvell
lsusb | grep -i marvell
iw list

The presence of

alone does not prove exposure. The system must also be operating the affected adapter as an AP, and the vulnerable station-association path is specifically relevant to the 802.11n-capable AP handling described in the fix. Still, kernel updates are preferable to trying to infer every runtime condition on deployed hardware.

Until an updated kernel is installed, systems that do not need hotspot functionality can reduce exposure by avoiding AP/uAP mode on the affected adapter. That is a mitigation, not a substitute for the patch: the driver’s firmware-event parser remains present, and configuration can drift over the life of an appliance.

The practical next step is to update to the fixed vendor kernel package, reboot into it, and confirm the running release with

. For embedded images pinned to a custom kernel, backport the upstream validation patch rather than attempting a transport-level length check. CVE-2026-68326 was fixed where the firmware-controlled field becomes meaningful, against the one buffer every

transport has in common.