Linux users with Qualcomm‑based Wi‑Fi adapters face a new, proximity‑based threat: a rogue access point can force their device’s firmware to crash, causing abrupt disconnections and potential system instability. The vulnerability, tracked as CVE‑2025‑68380, was disclosed through the Linux kernel’s security process and has already been patched in stable kernel branches. If you use a laptop, embedded system, or virtual machine that relies on the in‑tree ath11k driver—common in many devices with Qualcomm WCN and QCA chips—you need to update your kernel now.

A single flipped assignment, a device‑level crash

The root cause is a logic error inside ath11k_wmi_send_peer_assoc_cmd, the function that builds the peer association command for the firmware. When translating HE‑MCS (High‑Efficiency Modulation and Coding Scheme) capabilities—used by Wi‑Fi 6 and 6E to negotiate speed and spatial streams—the driver accidentally swapped the peer’s transmit and receive bitmaps. As a result, a malformed value from a peer could land in the wrong firmware field.

Specifically, an access point that advertises the out‑of‑spec Tx HE‑MCS Map for 160 MHz as 0xffff would cause that invalid mask to be written into the rx_mcs_set field. On affected Qualcomm chipset firmware, this triggers a firmware crash. The fix, merged upstream, is a direct swap: the peer’s TX mask now goes to the firmware’s transmit field, and the RX mask to the receive field. It’s a one‑line logic correction that doesn’t touch rate‑control algorithms or other complex subsystems.

Qualcomm chips tested against the fix include the WCN6855 and QCN9274—platforms found in laptops, consumer access points, and various embedded devices. Any kernel that builds and loads the ath11k driver is exposed; if your distribution uses an out‑of‑tree vendor stack instead, you may be safe, but most mainline‑based distros are affected.

Why this matters for your hardware

For everyday users

If you run a Linux laptop with a Qualcomm Wi‑Fi card (common in some Dell, Lenovo, HP, and Asus models) and you connect to public hotspots, coffee‑shop Wi‑Fi, or any network you don’t fully control, you’re at risk. An attacker within radio range can set up a malicious AP that sends the crafted capability information during association. Your machine’s firmware will crash, Wi‑Fi disconnects, and depending on the system, you may need a full reboot or experience repeated firmware recovery cycles. There’s no evidence the bug can be exploited for remote code execution—the immediate impact is a denial of service—but persistent crashes can disrupt work, drop important connections, and in some cases cause system logs to balloon.

For IT administrators

Fleet managers should treat this as a high‑priority patch for any Linux endpoint that moves between networks. Road warriors, reception‑area kiosks, and devices used in shared workspaces are especially exposed. Even guest VMs running on hypervisors can be affected if they pass through or emulate Qualcomm Wi‑Fi hardware—the vulnerability lives in the guest kernel’s driver. Inventory your hosts with lsmod | grep ath11k and prioritize those that appear in dynamic network environments.

For embedded and IoT deployments

This is where the long‑tail risk lives. Many embedded devices—Wi‑Fi routers, industrial controllers, digital signage, medical devices—use Qualcomm chips and run customized Linux kernels that receive updates infrequently. The upstream fix is trivial to backport, but the real challenge is getting it into OEM firmware images. If you manage such appliances, contact the vendor for a patched image. In the meantime, consider network‑level segmentation to limit exposure to rogue APs.

How we got here: A subtle Wi‑Fi 6 negotiation breakdown

Wi‑Fi 6 uses HE‑MCS bitmaps to agree on supported modulation schemes and spatial streams. These bitmaps are parsed by both the kernel and firmware with strict semantics. The ath11k driver has been part of the mainline kernel for several years, supporting Qualcomm’s Wi‑Fi 6/6E products. The field‑swap bug was likely present from the driver’s introduction but remained dormant because most legitimate access points never send a 0xffff map—the value is explicitly disallowed by the 802.11ax specification.

Researchers or maintainers discovered the issue during testing or code review, and the fix was fast‑tracked into the stable kernel trees. The commit message and the CVE record note that the swapped assignment was a clear “copy‑paste” style oversight. It’s a reminder that even small semantic errors in driver‑firmware interfaces can have outsized consequences when firmware implementations fail gracefully.

What to do right now: a triage‑and‑patch checklist

  1. Confirm you’re affected. Open a terminal and run:
    lsmod | grep ath11k
    If you see output, the vulnerable driver is loaded. You can also check grep ATH11K /boot/config-$(uname -r) to see if the driver was built into your kernel.

  2. Update your kernel. Most major distributions have already shipped the fix. Use your package manager:
    - Debian/Ubuntu: sudo apt update && sudo apt upgrade and reboot.
    - Fedora: sudo dnf upgrade --refresh and reboot.
    - Arch Linux: sudo pacman -Syu and reboot.
    - For custom or embedded kernels, merge the stable commit corresponding to CVE‑2025‑68380 and rebuild.

  3. If you can’t patch immediately, reduce exposure.
    - Avoid connecting to any untrusted Wi‑Fi networks, especially in public places.
    - On hosts where Wi‑Fi is not essential, temporarily disable the module:
    echo "blacklist ath11k" | sudo tee /etc/modprobe.d/blacklist-ath11k.conf sudo modprobe -r ath11k
    This kills wireless connectivity but eliminates the attack surface until you can reboot into a new kernel.
    - For managed AP fleets, use VLAN segmentation and client isolation to limit what a malicious peer can reach.

  4. Verify the fix. After rebooting, confirm the new kernel version with uname -a and check that ath11k is still present (if you need it). Monitor kernel logs for a few days:
    journalctl -k | grep -i ath11k dmesg | grep -i firmware
    You should no longer see spontaneous firmware‑crash traces immediately after association.

Staying ahead of proximity threats

CVE‑2025‑68380 underscores an evolving attack pattern: as modern Wi‑Fi stacks grow more complex, bugs in driver‑firmware interaction become attractive for denial‑of‑service and potentially more severe exploitation. The good news is that the upstream Linux community responded quickly, and the fix is safe to deploy widely. The lingering risk lies in unpatched embedded devices and the long tail of older kernels—a problem that only proactive inventory and vendor pressure can solve.

For users, the lesson is clear: kernel security patches are not optional. A malicious actor who gets within radio range of your laptop shouldn’t be able to crash your Wi‑Fi with a single malformed management frame. Update now, and stay updated.