CVE-2025-39732: Linux ath11k fix and Azure Linux attestation

A small but important correctness fix in the Linux ath11k Wi‑Fi driver — tracked as CVE‑2025‑39732 — landed upstream this year after maintainers discovered an iterator that may sleep when called from an atomic context, and Microsoft’s public advisory has named Azure Linux as the Microsoft product known to include the upstream code; that attestation is authoritative for Azure Linux, but it is not a categorical guarantee that no other Microsoft product could contain the same vulnerable kernel code.

Background / Overview​

The flaw fixed by CVE‑2025‑39732 is compact and technical: the ath11k driver passed ath11k_mac_disable_peer_fixed_rate() as the iterator to ieee80211_iterate_stations_atomic(), but that iterator can sleep — violating the atomic-context requirement and producing kernel BUG/warning traces such as “sleeping function called from invalid context.” The upstream remedy was to switch to ieee80211_iterate_stations_mtx(), avoiding the atomic-context requirement and eliminating the sleep-in-atomic condition. This is a correctness fix that reduces the risk of kernel warnings, potential hangs, or crashes on hosts that load the ath11k module.
The affected code lives in the ath11k Linux kernel driver (Qualcomm/ Atheros 802.11ax family). ath11k has been part of mainline kernel trees since roughly Linux 5.6 and is the standard Linux path for Qualcomm 11ax Wi‑Fi chipsets including families like WCN6855, QCA6390/6391, IPQ series and others; distributions ship it when they enable the module in the kernel config. Because the vulnerability is in the kernel driver code rather than in remote network‑facing protocol parsing, the practical exploitation profile is limited: these bugs typically cause local stability issues (kernel warnings, oops, hangs) rather than direct remote code execution. Nevertheless, production hosts and appliances that rely on wireless networking or carry Wi‑Fi chipsets should treat this as a reliability/availability risk and patch promptly.

---

What Microsoft actually said — and what that wording means​

Microsoft’s Security Response Center (MSRC) pages for a number of Linux kernel CVEs (including the ath11k family and similar kernel fixes) include an FAQ-style answer: “Azure Linux includes this open-source library and is therefore potentially affected” and note Microsoft began publishing machine-readable CSAF/VEX attestations in October 2025; they add they will update the CVE if impact to additional Microsoft products is found. That wording hs multiple Linux-related CVE entries on MSRC.
Put plainly:

• Definitive: Microsoft has inspected and attested that Azure Linux images/builds include the implicated upstream component (here, ath11k), so Azure Linux customers should assume they may be affected and follow the vendor guidance.
• Non‑definitive: That attestation is product-scoped and time-boxed.eacts — WSL kernels, cloud marketplace images, container base images, appliance/partner images, or other Microsoft-maintained Linux kernels — are free of the same upstream code. Absent an explicit VEX/CSAF attestation for another product, the safe operational assumption is “unverified” rather than “not affected.” Recent analyst and community writeups have emphasized this exact distinction.

In short: Microsoft’s public statement identifies Azure Linux as a confirmed carrier of the upstream library; it does not imply exclusivity.

---

The technical fix and its scope​

What changed in the kernel​

• The bug is a context/locking correctness issue: an iterator that can sleep was being invoked via ieee80211_iterate_stations_atomic(), which requires atomic-safe iterators. The iterator could block via code paths that call into WMI/firmware interactions which are allowed to sleep.
• Upstream maintainers replaced the atomic iterator call with ieee80211_iterate_stations_mtx(), which requires holding the mac80211 mutex and permits sleeping inside the iterator. This removes the atomic-context violation and is the accepted fix path.

Which kernels and devices are relevant​

• Any kernel build that includes the ath11k module (drivers/net/wireless/ath/ath11k) and that uses a kernel version or patch set older than the stable commits containing the fix is potentially affected. The specific hardware mentioned in the upstream testing notes includes Qualcomm WCN6855 hw2.0 (PCI WLAN). Not every system will exhibit the BUG trace; exposure depends on whether the relevant code paths and hardware are present and invoked. ([cvefd025-39732)

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No — not necessarily. Azure Linux is the only Microsoft product Microsoft has publicly attested to include the implicated upstream code at the time of their advisory, but that attestation is an inventory statement for Azure Linux rather than an exclusion of other Microsoft artifacts. Other Microsoft-distributed kernels or images could include the same upstream driver depending on the kernel version and how the kernel was configured at build time.
Why this matters in practice:

• Kernel content is an artifact-level property. A single upstream source file (e.g., drivers/net/wireless/ath/ath11k/…) can appear in many different builds and products if the vendor or image builder uses the same kernel version or merges the same upstream commit range.
• Microsoft maintains multiple Linux‑ezure kernel variants for VM SKUs, some images used for Azure Kubernetes Service nodes, Marketplace VM images, WSL kernels distributed to Windows users, and other internal/partner appliances. Each artifact uses a kernel build configured for its environment; some will include ath11k, others may omit it (for example, minimal hypervisor kernels typically drop device drivers such as PCI Wi‑Fi paths). The mere presence of an upstream fix in one product’s attestation does not prove the same code is absent from every other product.

Concrete operational implication: if you run Azure Linux, treat Microsoft’s attestation as authoritative and apply the Azure Linux kernel update. If you run other Microsoft-distributed artifacts (WSL, marketplace images, AKS node images supplied by Microsoft, CBL-Mariner derivatives used inside Azure services), validate locally and ask Microsoft for expanded VEX attestations or check the actual kernel build and module list.

---

How to check whether a host (including Microsoft-provided images) is affected​

Follow this practical checklist to determine exposure and remediate:

• Inventory hosts that may load ath11k:
• Check loaded modules: lsmod | grep ath11k
• Inspect kernel config for module support: grep -i ATH11K /boot/config-$(uname -r)
• Look for the driver on disk: find /lib/modules/$(uname -r) -name 'ath11k*'
• Inspect kernel logs for symptoms:
• journalctl -k | grep -i 'sleeping function called from invalid context|ath11k'
• dmesg | grep -i ath11k
• Confirm kernel package versions:
• On Debian/Ubuntu: dpkg -l | grep linux-image
• On RHEL/SUSE/Oracle: rpm -q kernel
• Compare the installed kernel re vendor advisories and upstream stable commit ranges that include the fix. Debian and vendor trackers list fixed versions per release.
• For Microsoft images:
• If you use Azure Linux images, rely on Microsoft’s MSRC attestation and applied Azure Linux security updates.
• If you use other Microsoft artifacts (WSL, Marketplace images), explicitly check the kernel build and module list on the running instance. Do not assume “not affected” just because MSRC only named Azure Linux.

---

Mitigation and remediation steps​

• Apply vendor-supplied kernel updates as soon as they arrive for your distribution or image. Distribution trackers (Debian, SUSE, Oracle, Amazon Linux trackers) have already incorporated upstream stable commits and listed fixed versions for specific branches. If you rely on vendor images from Microsoft (Azure Linux), apply the provided Azure Linux kernel/security update immediately.
• If patching is delayed and wireless functionality is not essential on a host, temporarily blacklist the ath11k module to prevent it from loading:
• echo "blacklist ath11k" > /etc/modprobe.d/blacklist-ath11k.conf
• modprobe -r ath11k
  This is a disruptive workaround — it removes Wi‑Fi support — and is not appropriate for devices that require wireless connectivity. Use with caution.
• For managed fleets: prioritize devices where Wi‑Fi is exposed to untrusted networks (APs, gateways, client machines operating on guest networks). Those hosts are higher value targets for reliability exploits or surprising firmware interactions.
• If you operate Microsoft-supplied images beyond Azure Linux:
• Request VEX/CSAF expansion from Microsoft for the other artifact families you run (WSL kernels, AKS node images, marketplace images) or perform local kernel inventory to confirm presence/absence of ath11k. Microsoft has committed to update CVE records if additional products are identified; customers should push for timely expanded attestations.
• For custom kernels: merge the upstream stable commit that switches iterate_stations_atomic() to iterate_stations_mtx(), rebuild and redeploy. The change is small and straightforward to backport to stable kernel branches. Upstream commit identifiers and stable backports are tracked in public CVE trackers.

---

Risk analysis: severity, exploitability, and real-world impact​

• Severity: multiple trackers assign a medium severity to CVE‑2025‑39732 (CVSS scores vary across trackers). The vulnerability is a correctness/availability class issue rather than a memory corruption permitting remote code execution. Typical impact is kernel warnings, potential oops or hard hang under specific workloads and hardware.
• Exploitability: the issue is not known to enable remote code execution. It arises from local code running in kernel context (driver callbacks iterating station lists). In practice, it’s a reliability/availability problem rather than a classical remote RCE. Nonetheless, for embedded or appliance contexts where an attacker can induce repeated operations that trigger the iterator (for example via crafted management frames or orchestrated firmware requests), instability might be forced.
• Exposure surface: any host that both (a) contains the ath11k driver in its kernel build and (b) runs hardware with affected Qualcomm chipsets (or exercises the driver paths) is potentially exposed. Many cloud VM images and hypervisor-hosted guest imagrect Wi‑Fi hardware to guests; in those cases, the binary driver may be present in the image but not loaded, reducing exposure. However, physical devices and VM images with PCI passthrough of Wi‑Fi hardware, embedded appliances, and some thin images for edge devices are higher risk.

---

Why Microsoft’s attestation model is good — and where it falls short​

Microsoft’s move to publish machine-readable CSAF/VEX attestations (starting October 2025) is an important industry step: it gives customers a structured way to learn which Microsoft products include which upstream components and thus which CVE level of transparency materially improves triage speed for defenders and reduces ambiguity. Microsoft’s public attestation that Azure Linux includes the implicated open‑source code is therefore an operational win: it tells Azure Linux customers to patch.
But there are limits:

• Product scope vs artifact scope: Microsoft’s initial attestations prioritize Azure Linux; the model is product-scoped. That means other artifacts may remain unverified until Microsoft expands attestations. Customers running diverse Microsoft-supplied artie the absence of an attestation equals absence of vulnerability.
• Timing and coverage: producing exhaustive attestations across all product families and historical kernel build variants is nontrivial. Microsoft’s pledge to update CVE records if further affected products are found is good, but defenders should treat the first attestation as the minimum scope of confirmed exposure and perform local verification for everything else.
• Operational dependency: many enterprises depend on vendor attestations to prioritize patch windows. The practical consequence is that vendors should accelerate expanding VEX attestations to other product families that ship Linux kernels; customers should ask vendors for confirmation for the specific images they consume.

---

Recommendation checklist for sysadmins and security teams​

• Prioriinux images immediately if you run them — follow Microsoft’s Azure Linux update guidance and apply kernel updates.
• Inventory Microsoft-provided artifacts in your estate:
• List images you run (Azure Marketplace, AKS node SKUs, WSL kernel versions, CBL-Mariner builds)
• Query running kernels for ath11k and kernel version metadata
• For each artifact, answer these questions:
• Does the kernel build include ath11k? (grep /boot/config-$(uname -r))
• Is the module loaded? (lsmod)
• Are there kernel log traces referencing ath11k errors? (journalctl/dmesg)
• If patching will be delayed, limit exposure:
• Avoid exposing unpatched hosts to untrusted Wi‑Fi networks
• Consider blacklisting ath11k where Wi‑Fi is nonessential
• Ask Microsoft for device- or image-specific VEX attestations for any Microsoft artifact you operate beyond Azure Linux; track vendor advisories and fixed kernel package versions for the distro you run.
• If you build or ship custom kernels, merge the upstream stable commit replacing atomic iteration with mtx iteration and rebuild. Confirm backports exist for your stable kernel branch.

---

Final takeaways​

CVE‑2025‑39732 is a precise, low‑surface-area kernel correctnessvep-in-atomic call path by switching to a mutex‑based iterator. The vulnerability presents a reliability/availability risk for hosts that include and load the ath11k module and that exercise the relevant code paths; it does not currently appear to enable remote code execution. Upstream and multiple distributors have published fixes and advisories; operators should apply vendor kernel updates promptly.
Microsoft’s MSRC attestation that Azure Linux includes the implicated open‑source library is authoritative for Azure Linux and should be acted on by Azure Linux customers, but it is not an exclusionary statement about all Microsoft products — other Microsoft artifacts could still contain the same upstream code depending on kernel version and build configuration. Treat Microsoft’s VEX/CSAF attestation as a reliable starting point and perform artifact-level verification for every Microsoft-supplied image or kernel you run.
Operators who want to reduce uncertainty should couple vendor attestations with local inventory (lsmod, kernel config checks, dmesg/journalctl) and with a request for extended VEX/CSAF coverage from Microsoft for the specific Microsoft artifacts they depend on. In the short term, patch Azure Linux and other affected distributions; in the medium term, increase product-level visibility by demanding broader machine-readable attestations and maintain a lean, auditable kernel inventory for your environment.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center