CVE-2026-63822 fixes a double-free condition in the Linux kernel’s Qualcomm ath11k Wi‑Fi driver, a bug that can trigger a kernel warning and unstable teardown path after a firmware-related initialization failure. The flaw is now tracked in the National Vulnerability Database after kernel.org published the fix across supported stable branches on July 19, 2026.
For Windows users, this is not a vulnerability in Windows 11’s native Wi‑Fi stack or Qualcomm’s Windows driver. Its relevance is narrower but real: administrators and enthusiasts running Linux on bare metal, in dual-boot setups, or with PCIe Wi‑Fi passthrough into Linux virtual machines should make sure their guest or host kernels include the corrected ath11k code. The issue is particularly easy to reproduce in virtualized configurations where a Qualcomm Wi‑Fi adapter is passed through and Message Signaled Interrupt addressing fails during device startup.
According to the NVD record sourced from kernel.org, the vulnerable code lives in
The sequence begins when ath11k encounters an error while bringing up firmware. As part of that failure path, the driver releases transmit-status buffers associated with
The problem arrives later, when the PCI driver is unbound or the device is removed. The ath11k teardown path runs its cleanup routine again and attempts to free the same transmit-status buffers for a second time. Linux’s SLUB allocator detects the invalid release and produces a warning trace involving
That makes the CVE’s headline—“fix warning when unbinding”—sound deceptively minor. A warning is the visible symptom; the underlying condition is a double free. In kernel development, a double free deserves prompt treatment even where the currently documented outcome is a warning rather than a demonstrated privilege-escalation path.
The upstream commit, authored by José Ignacio Tornos Martinez and accepted through the ath11k maintenance tree, takes the smallest possible corrective action: after freeing each transmit-status buffer, the driver sets its pointer to
Mailing-list discussion around the patch adds helpful context. The reporter identified a QCNFA765 adapter during testing, but the maintainers treated the defect as an ath11k driver cleanup problem rather than a flaw unique to that card. The same class of unbind-after-failed-start behavior had previously been addressed in the newer ath12k driver family.
That distinction matters to IT teams. A Linux VM normally uses a virtual network adapter and will never load ath11k. The exposure surface opens when a physical Qualcomm wireless device is presented directly to the guest through PCIe passthrough, such as VFIO-based labs, workstation virtualization, hardware validation environments, or specialized edge deployments.
The issue can also matter outside a VM. Any Linux system using ath11k hardware that experiences the relevant firmware startup failure and then removes, resets, or unbinds the driver can reach the affected cleanup path. Still, the public technical record points to virtualization as the most reliable reproduction environment, not to ordinary day-to-day Wi‑Fi use on a laptop.
That is good news for organizations that consume standard distribution kernels, but it does not automatically mean every installed system has received the update. Enterprise distributions often backport individual security and stability patches into a vendor kernel whose public version does not match the upstream stable release number. A host running a kernel labeled below one of the upstream fixed points may already be protected; conversely, an appliance or custom image can remain exposed long after upstream commits are available.
There is also no public evidence in the NVD entry that this CVE is being exploited, remotely reachable through Wi‑Fi traffic, or assigned a severity rating. NIST lists CVSS v2, v3, and v4 assessments as unavailable. Administrators should avoid filling that gap with assumptions: this is a documented kernel double-free bug with a known local failure sequence, not yet a scored or fully characterized security exploit.
For environments that use PCI passthrough, validation should focus on the failure lifecycle as well as ordinary connectivity. A clean Wi‑Fi association test does not exercise this defect. The useful checks are whether firmware-start failure is handled cleanly, whether an
A concise priority list for affected environments is:
For Windows users, this is not a vulnerability in Windows 11’s native Wi‑Fi stack or Qualcomm’s Windows driver. Its relevance is narrower but real: administrators and enthusiasts running Linux on bare metal, in dual-boot setups, or with PCIe Wi‑Fi passthrough into Linux virtual machines should make sure their guest or host kernels include the corrected ath11k code. The issue is particularly easy to reproduce in virtualized configurations where a Qualcomm Wi‑Fi adapter is passed through and Message Signaled Interrupt addressing fails during device startup.
According to the NVD record sourced from kernel.org, the vulnerable code lives in
drivers/net/wireless/ath/ath11k/dp.c and has existed since Linux kernel 5.6. NIST had not assigned a CVSS score as of July 20, 2026, so this should not be treated as a confirmed remote-code-execution or network-exposure event. It is, instead, a memory-management defect in an error-and-unbind sequence—a reliability issue that has been assigned a CVE because the faulty lifetime handling can cause a double free in kernel space.
The crash happens after the first failure
The sequence begins when ath11k encounters an error while bringing up firmware. As part of that failure path, the driver releases transmit-status buffers associated with dp->tx_ring*.tx_status. That cleanup is appropriate at the time: the hardware initialization has failed and the buffers are no longer needed.The problem arrives later, when the PCI driver is unbound or the device is removed. The ath11k teardown path runs its cleanup routine again and attempts to free the same transmit-status buffers for a second time. Linux’s SLUB allocator detects the invalid release and produces a warning trace involving
free_large_kmalloc, ath11k_dp_free, ath11k_core_deinit, and ath11k_pci_remove.That makes the CVE’s headline—“fix warning when unbinding”—sound deceptively minor. A warning is the visible symptom; the underlying condition is a double free. In kernel development, a double free deserves prompt treatment even where the currently documented outcome is a warning rather than a demonstrated privilege-escalation path.
The upstream commit, authored by José Ignacio Tornos Martinez and accepted through the ath11k maintenance tree, takes the smallest possible corrective action: after freeing each transmit-status buffer, the driver sets its pointer to
NULL. A later teardown call can then safely pass through the same cleanup function without attempting to release already-freed memory.Virtual machines make the bad path easy to hit
The kernel.org description says the condition is consistently reproducible in a virtual machine because MSI addressing initialization fails there. The reproducer involves an ath11k PCI device—typically a Qualcomm Wi‑Fi 6-class adapter—passed through to a VM, followed by an explicit unbind ofath11k_pci after initialization breaks.Mailing-list discussion around the patch adds helpful context. The reporter identified a QCNFA765 adapter during testing, but the maintainers treated the defect as an ath11k driver cleanup problem rather than a flaw unique to that card. The same class of unbind-after-failed-start behavior had previously been addressed in the newer ath12k driver family.
That distinction matters to IT teams. A Linux VM normally uses a virtual network adapter and will never load ath11k. The exposure surface opens when a physical Qualcomm wireless device is presented directly to the guest through PCIe passthrough, such as VFIO-based labs, workstation virtualization, hardware validation environments, or specialized edge deployments.
The issue can also matter outside a VM. Any Linux system using ath11k hardware that experiences the relevant firmware startup failure and then removes, resets, or unbinds the driver can reach the affected cleanup path. Still, the public technical record points to virtualization as the most reliable reproduction environment, not to ordinary day-to-day Wi‑Fi use on a laptop.
What has been fixed—and what has not been established
The correction has been backported into multiple maintained stable-kernel lines. The NVD’s affected-version data identifies Linux 5.6 and later as affected before their respective stable fixes, while specifically listing corrected points including Linux 5.10.260, 5.15.211, 6.1.177, and 6.6.144. The record also links eight stable-tree commits, indicating the patch has moved through a broad set of supported kernel branches rather than remaining only in upstream development.That is good news for organizations that consume standard distribution kernels, but it does not automatically mean every installed system has received the update. Enterprise distributions often backport individual security and stability patches into a vendor kernel whose public version does not match the upstream stable release number. A host running a kernel labeled below one of the upstream fixed points may already be protected; conversely, an appliance or custom image can remain exposed long after upstream commits are available.
There is also no public evidence in the NVD entry that this CVE is being exploited, remotely reachable through Wi‑Fi traffic, or assigned a severity rating. NIST lists CVSS v2, v3, and v4 assessments as unavailable. Administrators should avoid filling that gap with assumptions: this is a documented kernel double-free bug with a known local failure sequence, not yet a scored or fully characterized security exploit.
The practical response is to patch, not to disable Wi‑Fi
Linux administrators should update to the newest kernel supplied by their distribution or kernel vendor, then reboot into that kernel where operationally appropriate. Teams that compile custom kernels, use pinned long-term-support builds, or maintain hypervisor images should verify that their ath11kdp.c contains the nulling change after the transmit-status buffer release.For environments that use PCI passthrough, validation should focus on the failure lifecycle as well as ordinary connectivity. A clean Wi‑Fi association test does not exercise this defect. The useful checks are whether firmware-start failure is handled cleanly, whether an
ath11k_pci unbind or device removal produces allocator warnings, and whether the guest remains stable after the failure.A concise priority list for affected environments is:
- Update Linux guests and bare-metal hosts that use Qualcomm ath11k wireless hardware to a vendor kernel containing the backport.
- Give extra urgency to VM and test-lab systems using PCIe passthrough for Qualcomm Wi‑Fi devices.
- Review kernel logs for
free_large_kmalloc,ath11k_dp_free, andath11k_pci_removeif prior firmware-start failures or device-reset issues have been reported. - Do not classify Windows endpoints as affected solely because they contain a Qualcomm Wi‑Fi adapter; Windows uses a separate driver stack.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:05:34-07:00
- Security advisory: MSRC
Published: 2026-07-20T01:05:34-07:00
Original feed URL
*Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
