A memory‑management bug in the Linux kernel’s Qualcomm Atheros Wi‑Fi 7 driver — tracked as CVE‑2025‑37744 and described as “wifi: ath12k: fix memory leak in ath12k_pci_remove()” — has been fixed upstream, and Microsoft’s public advisory currently identifies Azure Linux as a product that “includes this open‑source library and is therefore potentially affected.” That phrasing is accurate but narrow: it is an attestation of inventory for Azure Linux, not an assertion that no other Microsoft product could ship the same vulnerable code. In practice, the correct operational posture for defenders is to treat Azure Linux as a confirmed carrier while treating other Microsoft artifacts as unknown until verified, and to take immediate mitigation steps if an affected ath12k driver is present in any kernels they operate. (osv.dev)
CVE‑2025‑37744 is a resource‑management flaw in the ath12k PCI driver used for Qualcomm Wi‑Fi 7 hardware (devices such as QCN9274 and WCN7850). The upstream fix ensures that firmware memory allocated during probe is always freed in the removal path — specifically, calling ath12k_fw_unmap() when the ATH12K_FLAG_QMI_FAIL path is taken — closing a scenario where kmemleak reported unreferenced allocated objects. The bug is categorized as a memory leak (CWE‑401) and has moderate operational impact: a local actor could repeatedly trigger the faulty path and gradually exhaust kernel memory resources, causing degraded stability or denial of service.
Why this matters now: the ath12k driver is new (added during the Linux 6.3 cycle to support Wi‑Fi 7 hardware) and is already present in many distribution kernel trees and in firmware‑bundles; any kernel build that includes the ath12k module and exposes the affected PCI device families is potentially in scope until patched.
A few operational notes:
But the limits are equally important:
Meanwhile, most mainstream distributions and cloud vendors will continue to publish kernel updates and security notices mapping upstream fixes into distribution packages. Rely on vendor packages for production patching unless you have a validated kernel backport process.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE‑2025‑37744 is a resource‑management flaw in the ath12k PCI driver used for Qualcomm Wi‑Fi 7 hardware (devices such as QCN9274 and WCN7850). The upstream fix ensures that firmware memory allocated during probe is always freed in the removal path — specifically, calling ath12k_fw_unmap() when the ATH12K_FLAG_QMI_FAIL path is taken — closing a scenario where kmemleak reported unreferenced allocated objects. The bug is categorized as a memory leak (CWE‑401) and has moderate operational impact: a local actor could repeatedly trigger the faulty path and gradually exhaust kernel memory resources, causing degraded stability or denial of service.Why this matters now: the ath12k driver is new (added during the Linux 6.3 cycle to support Wi‑Fi 7 hardware) and is already present in many distribution kernel trees and in firmware‑bundles; any kernel build that includes the ath12k module and exposes the affected PCI device families is potentially in scope until patched.
What Microsoft actually said — and what it doesn’t mean
Microsoft’s advisory language, repeated across several MSRC CVE pages, is consistent:- Microsoft explicitly notes that Azure Linux (the Microsoft‑maintained distribution descended from CBL‑Mariner) includes the implicated open‑source component and is therefore potentially affected.
- Microsoft also explains that it began publishing CSAF/VEX (machine‑readable attackability/attestation outputs) in October 2025 and that the company will update CVE entries if additional Microsoft products are identified as carriers. This is a statement about disclosure process and inventory cadence, not a technical exclusion.
The technical detail: what the bug is, exactly
The vulnerability is narrowly scoped and technical:- Root cause: firmware memory allocated via the ath12k driver’s probe path (ath12k_pci_probe()) was not released on one failure path in ath12k_pci_remove() when the ATH12K_FLAG_QMI_FAIL bit is set. The fix adds a call to ath12k_fw_unmap() in the removal path so the firmware allocations are cleaned up.
- Observability: upstream maintainers observed kmemleak reports showing unreferenced objects and provided a stack backtrace tied to firmware allocation and pci device probe paths. That diagnostic trace is how the leak was diagnosed and confirmed.
- Impact: the flaw is not a remote code execution or privilege escalation vulnerability by itself. It is a local resource exhaustion problem: repeated triggering could cause kernel memory growth and instability. As a result, the operational impact is availability‑focused.
- Tested hardware: fixes were validated on WCN7850 hw2.0 PCI WLAN silicon. Administrators with that hardware — or similar hardware families supported by ath12k — should pay particular attention.
Is Azure Linux the only Microsoft product that includes the library?
Short answer: No — not necessarily, and here’s why.- Azure Linux is the only Microsoft product Microsoft has publicly attested so far to include the implicated upstream driver for this CVE. That attestation is authoritative for Azure Linux artifacts — it is Microsoft saying “we have inspected these images and they carry the code.” (archive.ph)
- However, Microsoft produces and distributes other Linux kernel artifacts (the WSL2 kernel source and binary images, Azure Marketplace images, linux‑azure kernel builds used by some VM SKUs, AKS node images, etc.). Whether any of those artifacts actually include the ath12k driver depends on three concrete, build‑time factors: the kernel version, the kernel config (which drivers were compiled in or left as modules), and whether the particular artifact includes the specific firmware blobs and PCI support for the affected hardware. The presence/absence is artifact‑level, not vendor‑level. (github.com)
- Microsoft’s public wording deliberately avoids an unconstrained claim. It says Azure Linux includes the library and Microsoft will update the CVE if more products are discovered to ship it. That reflects a phased, inventory‑first approach to machine‑readable VEX/CSAF disclosures rather than a denial that other products might carry the code.
Where else might ath12k appear within Microsoft-deerators and security teams should consider at least these Microsoft‑distributed artifacts as potential places where ath12k could exist:
- Azure Linux (attested). This is the confirmes checked and listed.
- The Microsoft WSL2 kernel (microsoft/WSL2‑Linux‑Kernel). This is an actual kernel source tree Microsoft publishes and builds for Windows Subsystem for Linux; the repo’s configuration may include or exclude wireless drivers on purpose, depending on the WSL configuration. A direct search of the WSL2 kernel source in the public repo shows that ath12k is not present in that particular source snapshot, but kernel trees and configs change; operators should not assume WSL kernels are immune across all versions. Inspect your particular WSL kernel build (and the modules.vhdx content) if you rely on WSL in environments where PCI wireless hardware is involved. (github.com)
- Marketplace VM images and custom Azure images. These images may embed distribution kernels or custom kernel packages that include hardware drivers. The presence of ath12k depends on the distribution and kernel build used inside the image.
- ure‑provided container hosts that run a kernel variant compiled with ath12k enabled. These are separate build pipelines and must be inventoried individually.
Practical detection and triage steps for administrators
If you operate Linux systems on Azure, on Windows with WSL2, or run Microsoft images, follow a prioritized triage path:- Inventory first — list kernel images and module sets across your estate. Identify hosts with kernels containing ath12k or with firmware blobs for WCN7850/QCN9274.
- Check running systems for loaded modules: run lsmod | grep ath12k and check dmesg for ath12k_pci messages. If the module is present but not loaded, inspect /lib/modules/$(uname -r) for ath12k.
- For containerized workloads or Marketplace images, inspect the image’s kernel or ask the image vendor whether the kernel contains ath12k or uses a Microsoft‑provided kernel.
- Apply vendor patches: update to a kernel version that includes the upstream patch or apply the distribution kernel update issued by your vendor. Ubuntu and several other distros have advisories referencing CVE‑2025‑37744 and provide updated kernel packages. Where vendor packages are not available, plan a kernel upgrade path.
- Short‑term mitigation: if you do not need the ath12k module, remove or blacklist it until a patched kernel is available. This is an operational workaround for systems that do not require the affected wireless hardware. (Note: blacklisting is a stopgap and not suitable where the hardware is required.)
- Monitor for leaks: on systems with heavy device probe/remove activity or where the vulnerable path could be triggered, enable kmemleak or use kernel memory diagnostic tooling to look for rising unreferenced allocations tied to firmware_request paths.
Patch and vendor landscape
Multiple downstream distributors and tracking projects recorded CVE‑2025‑37744 shortly after the upstream fix. CVE trackers and vendor advisories (Ubuntu’s security notice, OSV, Amazon ALAS entries, and patched kernel trees) document the change and map the fix into packaging should rely on their distribution vendor’s kernel updates rather than attempting to manually patch production kernels, unless they have a disciplined kernel backport process.A few operational notes:
- Ubuntu and otherdded CVE entries and updated kernel packages. Verify your distribution’s security notice and apply updates from the official package channels.
- Cloud vendors often publish their own kernel builds and advisories; Azure Linux (Microsoft) has already attested the component and is managing updates for that distro family. Microsoft’s CSAF/VEX feed is intended to make impact and remediation status machine‑readable for Azure Linux.
Why vendor attestation (CSAF/VEX) matters — and its limits
Machine‑readable attestations like CSAF/VEX help automate triage: defenders can use those feeds to answer “which of my managed products are known to ship component X?” quickly and reliably for attested product families. Microsoft’s October 2025 rollout of CSAF/VEX for Azure Linux is an important step toward that operational transparency.But the limits are equally important:
- A VEX attestation is scoped to a product family and a set of artifacts; it never automatically covers a vendor’s entire catalog. A single Microsoft attestation for Azure Linux does not automatically apply to WSL kernels, Marketplace images, or AKS node images unless Microsoft explicitly attests those artifacts too. That is why absence of an attestation should be treated as “not yet verified.”
- VEX files can and should reduce false positives in vulnerability triage workflows, but they do not replace artifact‑level verification for high‑assurance environments. If you run critical workloads, you should still validate that the kernels you deploy do not include the vulnerable code path.
Risk analysis: who should worry most?
- Systems with on‑board or PCIe WCN7850/QCN9274 hardware (Wi‑Fi 7 client devicith ath12k enabled are the direct risk group. The vulnerability is local and availability‑centric; it is not a remote, wormable RCE vulnerability.
- Multi‑tenant hosts (cloud hypervisors) and network infrastructure appliances that accept local device add/remove cycles, or that expose privileged device paths to untrusted tenants, should be cautious because repeated triggering could be used to degrade availability.
- WSL2 usage on endpoint Windows boxes is lower risk in most configurations because the WSL2 kernel configuration often excludes many hardware drivers; however, if you (or a third‑party kernel) change the configuration or load additional modules into WSL modules.vhdx, you should verify whether ath12k is present. The WSL kernel repo is public and can be inspected for module lists. (github.com)
Recommended actions — prioritized checklist
- Immediate (days): inventory all kernels and modules across your estate for ath12k presence. Check running systems and images. Blacklist the module on systems that do not need it.
- Near term (weeks): apply distribution vendor or upstream vendor kernel updates that include the ath12k removal‑path fix; reboot when required. Validate the deployed kernel version matches the patched release noted in vendor advisories.
- Medium term (1–3 months): integrate Microsoft’s CSAF/VEX (and other vendors’ VEX outputs) into your vulnerability‑management pipeline to automate attestationnual triage. Track Microsoft’s VEX feed for new attestations beyond Azure Linux.
- Longer term: adopt artifact‑level verification (SBOMs, module lists, kernel config extraction) for any third‑party images you obtain from cloud marketplaces or vendors. Treat vendor attestations as high‑value inputs but always corroborate for critical workloads.
What to expect from vendors going forward
Microsoft’s public shift to machine‑readable VEX/CSAF and the explicit phrasing used on many MSRC CVE pages signals a disciplined, phased approach: start with Azure Linux, validate, publish VEX files, then expand coverage. Other vendors are following similar strategies to inventory where upstream open‑source components appear in their product families. That trend will improve automation for defenders, but it requires time and supplier cooperation to scale across large product catalogs.Meanwhile, most mainstream distributions and cloud vendors will continue to publish kernel updates and security notices mapping upstream fixes into distribution packages. Rely on vendor packages for production patching unless you have a validated kernel backport process.
Conclusion — the practical bottom line
- CVE‑2025‑37744 is a local memory‑leak bug in the ath12k driver that can cause availability problems if left unpatched. The upstream fix is straightforward and has been mapped into distribution advisories.
- Microsoft’s advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is a correct, product‑scoped attestation and a useful signal for Azure Linux operators. However, it is not a categorical statement that no other Microsoft product contains the code; other Microsoft artifacts must be verified per‑artifact. Treat un‑attested Microsoft artifacts as unknown and verify them.
- Operationally: inventory, apply vendor kernel updates, temporarily disable the ath12k module where feasible, and integrate VEX/CSAF inputs into your pipeline to automate future triage. Those steps will materially reduce your exposure and align your visibility to vendor attestations as Microsoft expands its VEX coverage.
Source: MSRC Security Update Guide - Microsoft Security Response Center
