CVE-2026-68355 closes an out-of-bounds read in the Linux ath11k Wi-Fi driver, but Windows PCs using a Qualcomm wireless adapter are not exposed through the native Windows driver stack. The practical audience is narrower: Linux installations that load ath11k for Qualcomm 802.11ax hardware, plus appliance, router, and embedded deployments carrying an affected kernel.

The newly published record, supplied by kernel.org and now listed by the National Vulnerability Database, identifies a boundary-checking error in

ath11k_hal_rx_msdu_list_get()

within

drivers/net/wireless/ath/ath11k/dp_rx.c

. Linux Wireless documentation identifies ath11k as the kernel driver for Qualcomm IEEE 802.11ax, or Wi-Fi 6, devices; it has been in the mainline kernel since Linux 5.6.

The important detail is that this is a receive-path parsing flaw. When the first element of an MSDU descriptor list reports a zero buffer address, the vulnerable logic can try to inspect the preceding element —

msdu_details[i - 1]

— while the index is zero. There is no preceding array entry. The code therefore reads before the beginning of the descriptor array.

Linux networking and cybersecurity illustration featuring Tux, routers, code, chips, and protective shields.The fix stops at the first empty descriptor​

The kernel change is small and specific. Before the existing code handles a zero buffer address by looking back at the prior descriptor, it now tests whether the index is already zero. If the first descriptor is empty, processing stops rather than dereferencing memory outside the array.

That distinction is worth spelling out. The old code treated any zero buffer address as a signal to complete metadata on the previous MSDU entry. That behavior is valid only after at least one descriptor has been processed. At the head of the list, “previous” is an invalid concept; the new guard makes that case explicit.

The patch was found by Linux Verification Center using SVACE, a static-analysis tool. The CVE description says the ath11k correction follows the already safer handling in

ath12k_wifi7_hal_rx_msdu_list_get()

, the corresponding path for newer Qualcomm Wi-Fi hardware. In other words, this was not a redesign of packet processing or a speculative mitigation. It is a targeted alignment of ath11k with a known-safe pattern already present elsewhere in the wireless subsystem.

The current mainline source as mirrored by Google’s Linux repository shows exactly that three-line protection: break out when the buffer address is zero on the first iteration, then retain the previous-descriptor logic for later entries. That independently confirms the CVE description and rules out a common ambiguity in newly issued kernel CVEs: whether the advisory describes a pending patch or code that has actually landed.

Affected since Linux 5.6, with fixes in maintained series​

The kernel.org CVE data marks the flaw as introduced with the ath11k driver’s original Linux 5.6-era commit. That does not mean every Linux system from 2020 onward needs emergency action. The driver must be present, enabled, and actually used by compatible Qualcomm Wi-Fi hardware before the vulnerable function becomes relevant.

Kernel.org’s version data identifies fixed releases in the active stable lines:

  • Linux 6.6.148 includes the fix for the 6.6 long-term branch.
  • Linux 6.12.101 includes the fix for the 6.12 long-term branch.
  • Linux 6.18.42 includes the fix for the 6.18 stable branch.
  • Linux 7.1.6 includes the fix for the 7.1 stable branch.
  • Linux 7.2-rc5 contains the upstream fix.

Administrators should not use a distro’s marketing kernel label as the decision point. A vendor can backport a fix without adopting the exact upstream version number, and a custom kernel can remain vulnerable even when the rest of the operating system is fully patched. Check the distribution’s kernel changelog or advisory for CVE-2026-68355, then compare the running kernel rather than the version installed on disk.

For a local confirmation, the two relevant questions are straightforward: whether the machine is running a kernel that includes the backport, and whether ath11k is in use.

uname -r

establishes the active kernel version;

lspci -nnk

or

lsusb -t

, depending on the platform, can show the network device and bound driver. On systems where ath11k is built as a module,

modinfo ath11k

will establish whether the driver is available, though availability alone is not proof that the hardware is using it.

A router, access point, thin client, industrial gateway, or laptop booted into Linux deserves more attention than a server with no wireless hardware. Ath11k supports both PCI-connected adapters and Qualcomm SoC platforms, which is why the exposure cannot be reduced to a short list of retail laptop models.


The advisory does not establish a remote exploit​

The NVD record currently has no CVSS 4.0, CVSS 3.x, or CVSS 2.0 assessment, and it does not assign a CWE classification. More significantly, the published description does not document an exploit chain, a proof of concept, attack prerequisites, or a demonstrated security impact beyond the invalid memory access.

That missing information should affect patch prioritization. A kernel out-of-bounds read can range from a reproducible stability fault to a more serious security primitive, but the CVE record does not support declaring this remote code execution, local privilege escalation, information disclosure, or a denial-of-service issue. Nor does it say that exploitation is occurring in the wild.

The trigger also sits in a hardware descriptor-processing path. The description establishes that a zero address in the first descriptor causes the unsafe access; it does not establish how an untrusted party can cause a deployed device to produce that malformed state. Firmware, DMA descriptors, monitor-mode paths, device resets, driver bugs, or unusual hardware behavior may all matter, but none are detailed in the public record.

The responsible conclusion is therefore operational rather than sensational: patch it as part of normal kernel maintenance, accelerate the work where ath11k devices process untrusted wireless traffic or where reliability is important, and do not invent an emergency network perimeter workaround that the advisory does not justify.

Why ordinary Windows and most WSL installs are different​

A Windows 10 or Windows 11 system does not run the Linux ath11k driver to operate its physical Qualcomm Wi-Fi adapter. It uses a Windows hardware driver supplied through Windows Update, the PC maker, or Qualcomm’s driver package. CVE-2026-68355 concerns Linux source file

drivers/net/wireless/ath/ath11k/dp_rx.c

, so updating Windows cumulative updates or a Windows Wi-Fi driver is not a remedy for this specific CVE — and is not necessary for it.

WSL 2 needs a more precise answer. Microsoft documents that WSL 2 runs a real Linux kernel in a lightweight managed virtual machine, but its normal networking arrangement uses a virtualized Ethernet adapter and NAT rather than directly binding the guest to the host’s physical wireless device. That architecture means a standard WSL 2 installation is not ordinarily loading ath11k to control the laptop’s Qualcomm Wi-Fi silicon.

There are exceptions worth checking rather than assuming away. Microsoft’s WSL kernel is a real Linux kernel that receives its own updates, and advanced users can supply a custom kernel. A custom WSL configuration that enables hardware passthrough or otherwise loads ath11k should be assessed as a Linux deployment. Microsoft’s public WSL kernel repository currently tracks a 6.18-based branch; the CVE data says the upstream 6.18 line is fixed at 6.18.42. That makes the exact WSL kernel build and Microsoft’s included backports the relevant evidence, not merely the fact that WSL is installed.

WSL 1 does not run a full Linux kernel and therefore does not contain this ath11k kernel path at all.

Patch the kernel where ath11k actually runs​

For desktop Linux users, the sensible route is the distribution’s normal kernel update, followed by a reboot into the new kernel. For fleet operators, inventory devices using Qualcomm Wi-Fi 6 hardware and look beyond employee laptops: network appliances and embedded products commonly lag upstream stable releases, and their kernel version may be opaque behind a vendor firmware image.

CVE-2026-68355 is a clean example of why kernel version management must account for both the running build and loaded drivers. The vulnerable logic has existed since Linux 5.6, yet the relevant fix is only a guard against the first entry in one receive descriptor list. Systems that do not run ath11k are outside the affected code path; systems that do should move to their vendor’s kernel containing the backport or to one of the fixed upstream releases.