CVE-2024-43861: Azure Linux Attestations and qmi_wwan Risk

Microsoft’s public advisory on CVE-2024-43861 names Azure Linux as a known carrier of the vulnerable upstream code — but that single attestation is not proof that Azure Linux is the only Microsoft product that could include the affected Linux kernel component. In plain terms: Azure Linux is the only Microsoft product Microsoft has publicly attested (via its VEX/CSAF program) to include the implicated qmi_wwan code so far, and Microsoft has committed to update those attestations if further Microsoft products are identified — however, other Microsoft-distributed kernels and images that ship a Linux kernel built from an affected upstream version could also be affected until they’re explicitly verified or patched. (msrc.microsoft.com)

---

Background / Overview​

CVE-2024-43861 is a Linux-kernel robustness issue in the USB WWAN driver qmi_wwan: when certain non‑IP packets arrive, the driver can retain an unused socket buffer (skb) instead of freeing it, producing a memory leak that, under sustained triggering, can lead to resource exhaustion and degraded availability. The fix upstream simply frees the unused skb where the code previously failed to do so. This is a correctness fix intended to stop progressive memory consumption and the attendant risk of system instability.
Why this matters to sysadmins and platform owners:

• qmi_wwan is the upstream kernel driver for USB-based Qualcomm QMI WWAN devices (cellular modems exposed over USB). Many Linux distributions include this driver as a loadable module or built‑in kernel object.
• The vulnerability’s attack vector is local — an unprivileged local actor (or a driver/modem input path that an attacker can influence) can trigger the code path repeatedly; over time, the host’s memory can be eaten by leaked skbs, producing denial-of-service conditions.

---

What Microsoft actually said — reading the attestation​

Microsoft’s Security Response Center entry for the CVE includes specific language: it states that Azure Linux includes the implicated open‑source component and is therefore potentially affected, and it also explains Microsoft’s broader transparency program — the company began publishing machine‑readable CSAF and VEX attestations in October 2025 and will update the CVE/VEX mappings if impact to additional Microsoft products is identified. That wording is deliberately product‑scoped: it is an authoritative inventory statement for Azure Linux artifacts, not a categorical claim that no other Microsoft product ships the component. (msrc.microsoft.com)
Two important operational takeaways from the MSRC wording:

• Attestation ≠ exclusivity. An MSRC product attestation means Microsoft confirmed the component exists in that product; it does not automatically declare other Microsoft artifacts unaffected.
• VEX/CSAF is a rolling program. Microsoft is publishing machine-readable attestations product-by-product, starting with Azure Linux; additional products will be added as Microsoft completes its inventory work. Customers should expect this to be an evolving mapping rather than a one-time, exhaustive inventory.

---

The technical landscape: where qmi_wwan lives and why that matters​

qmi_wwan is part of the upstream Linux kernel and is the standard kernel driver used for many USB-based Qualcomm WWAN modems. The driver is widely present in mainstream kernel trees and is enabled in many distro kernel configurations either as a module (recommended) or occasionally built-in. Because this is an upstream driver, any product that ships a Linux kernel built from an upstream tree that contains the vulnerable commit — and that builds or enables the driver — may carry the same risk until the kernel used by that product is patched or the module disabled.
This creates a simple truth for defenders: presence in source alone is not sufficient to prove exposure. To be exposed, an artifact must:

• include the vulnerable kernel version (or an unpatched backport of the buggy code), and
• have the driver built and either loadable or built into the running kernel image, and
• be able to receive the kind of input that triggers the non‑IP packet handling path (e.g., attached/managed USB WWAN modems providing QMI traffic).

If any of those three conditions is false for a particular product, that product is not practically vulnerable even if the source contains the file.

---

Which Microsoft artifacts could plausibly include qmi_wwan?​

Microsoft produces and distributes a surprising variety of Linux-based artifacts and kernel images. Any of these could, in principle, include the vulnerable driver depending on the kernel version and configuration used:

• Azure Linux images / Azure VM images — Microsoft explicitly attested Azure Linux; Azure VM images that use Microsoft-supplied kernel packages (Azure Linux) are therefore in-scope until patched. (msrc.microsoft.com)
• WSL2 (Windows Subsystem for Linux) kernel — Microsoft publishes the WSL kernel sources and distributes kernel binaries for WSL2. Whether the WSL kernel build contains qmi_wwan depends on the kernel configuration that Microsoft used when compiling each WSL kernel release; customers should not assume absence simply because WSL is a desktop-focused subsystem. Inspect the WSL kernel config or the shipped binary to confirm.
• CBL‑Mariner / Linux images used as Azure node bases or appliance kernels — Microsoft has historically maintained downstream kernel builds for cloud images and appliance-style artifacts. If those kernel builds included the WWAN subsystem, they could carry the driver. (Azure Linux is the start of Microsoft’s VEX rollout precisely because these cloud artifacts are high priority.)
• Azure Marketplace images and partner-provided images — marketplace artifacts are published by many vendors; some will ship kernels or modules that include qmi_wwan. The image publisher is responsible for kernel configuration and patching for their image, so each marketplace image must be treated individually.
• Edge / IoT images and appliance kernels — Microsoft supports various device and appliance images; any image that bundles a Linux kernel with the WWAN stack compiled could be affected.

Put plainly: Azure Linux is the only Microsoft product that Microsoft has publicly attested to include the code for CVE-2024-43861 so far, but other Microsoft-distributed kernels and images could be carriers depending on how they were built and configured. Treat the attestation as authoritative for Azure Linux, and treat other artifacts as unverified until you inspect them or Microsoft publishes a VEX attestation for them.

---

How you (as an operator) can verify whether a specific Microsoft artifact is affected​

There are three levels of verification you should perform, in order:

• Artifact-level inventory (quick check)
• Where your artifact runs, check whether the qmi_wwan driver is present in the running kernel:
• Run: lsmod | grep qmi_wwan
• Run: modinfo qmi_wwan (if present in /lib/modules/<kernel-version>)
• Inspect dmesg for qmi_wwan registration lines that indicate USB WWAN devices were enumerated.
• Kernel config check (definitive build-time evidence)
• Check the running kernel’s config (if available) to see if the driver was built-in or a module:
• Common methods: zcat /proc/config.gz | grep QMI_WWAN
• Or: grep CONFIG_QMI_WWAN /boot/config-$(uname -r)
• If you have a distributed kernel binary (for example WSL kernel image or Azure kernel package), examine the provided config file that shipped with that kernel. Microsoft publishes WSL kernel sources and config files; inspecting the shipped config will reveal whether CONFIG_QMI_WWAN was enabled.
• Binary / package-level check (artifact packaging)
• On package-based distros: query the kernel package contents to see whether modules/qmi_wwan.* is included in the kernel package for the installed kernel version.
• For WSL specifically: Microsoft publishes the kernel image and modules packaging process. If you run a stock WSL kernel distributed via Microsoft Update, examine the kernel release notes/config that correspond to the WSL kernel version you have installed.

If you find CONFIG_QMI_WWAN enabled or the module present and unpatched, treat the image as in-scope and plan remediation steps.

---

Practical detection commands and quick checklist​

Use these checks in order to build an inventory and prioritize remediation:

• Determine if the qmi_wwan module exists on the host:
• lsmod | grep qmi_wwan
• modinfo qmi_wwan
• Detect WWAN devices and qmi_wwan activity in dmesg:
• dmesg | grep -i qmi_wwan
• Confirm kernel config enabling of the driver:
• zcat /proc/config.gz | grep CONFIG_QMI_WWAN
• grep CONFIG_QMI_WWAN /boot/config-$(uname -r) || true
• Inspect installed kernel packages for the module:
• rpm -ql kernel-$(uname -r) | grep qmi_wwan (RPM-based)
• dpkg -L linux-image-$(uname -r) | grep qmi_wwan (DEB-based)
• For WSL: check the WSL kernel version and match it to Microsoft’s published kernel branch and config:
• uname -r
• Compare the kernel-release string to the WSL kernel branch published by Microsoft and inspect that branch’s config files.

Note: On WSL, custom kernels are supported and users sometimes install kernels with extra modules enabled — if you run a custom kernel, the presence or absence of the qmi_wwan module depends on your custom build’s config.

---

Remediation and mitigation guidance​

The straightforward remediation is to update the kernel to a patched upstream/stable release that contains the fix, or to apply your vendor’s kernel patches. In practice:

• Apply vendor kernel updates for the distribution in use (Azure Linux, Ubuntu, Red Hat, SUSE, Oracle Linux, Amazon Linux, etc.). Multiple distros and vendors backported the qmi_wwan fix into their stable kernels; consult the distro’s security advisory and apply the vendor kernel update.
• For Microsoft-managed images:
• If you run Azure Linux VM images, apply Microsoft’s published kernel patch or use updated Azure Linux images when they become available (Microsoft’s VEX/CSAF and security advisory pages will be updated as they roll out the fixes).
• If you run WSL2 with Microsoft’s kernel image, check Microsoft’s WSL kernel release notes and update WSL (wsl --update or use the Microsoft-published kernel that contains the fix) or rebuild a custom WSL kernel with the patched upstream commit applied. Microsoft makes the WSL kernel source available for inspection and custom builds.
• If patching is not immediately possible:
• Remove or blacklist the qmi_wwan module on systems that do not need WWAN modem support:
• echo "blacklist qmi_wwan" > /etc/modprobe.d/blacklist-qmi_wwan.conf
• Note: blacklisting is a mitigation only when you can safely confirm the host does not need USB WWAN modem functionality.
• For systems that use qmi_wwan (cellular modems required), mitigate by limiting local access to untrusted users and applying host-level resource limits (cgroups, ulimit) that can reduce risk from user-triggered leaks — but these are workarounds, not fixes.

Vendor advisories and vendor-supplied kernels are the authoritative source for remediation timelines; prioritize applying those in your environment. Multiple vendors have already published patches or backports for the qmi_wwan fix — confirm and deploy the vendor-specific package for your kernel branch.

---

Risk analysis — how serious is this, really?​

• Severity and exploitation vector. CVE-2024-43861 is a memory leak that has been scored in the medium range (CVSS ≈ 5.5 in many trackers). The attack vector is local — the attacker needs local access or the ability to send crafted non‑IP packets into the qmi_wwan processing path. That often implies physical or privileged access to a device-attached modem, or the ability to influence modem behavior via a connected network. Because the exploit requires repeated triggering to produce denial-of-service through memory exhaustion, this is not a typical remotely-exploitable remote code execution flaw, but it is operationally important for systems that host QMI devices or accept untrusted modem inputs.
• Real‑world exposure surface. Systems that attach USB cellular modems (for example, gateways, industrial controllers, field laptops, or some mobile computing platforms) are the highest-risk category. For cloud images (Azure Linux), the exposure depends on whether the image is used on VMs that have passthrough of USB WWAN devices or if customers attach such hardware. For WSL and desktop environments, exposure is lower in most cases because WSL instances rarely see direct USB WWAN devices unless the host forwards USB devices into WSL or the user runs a custom kernel with the module enabled.
• Potential impact. Left unpatched in a host that loads qmi_wwan and receives the triggering traffic pattern, the memory leak can lead to progressive memory consumption and eventual denial of service — degraded performance, OOM conditions, or kernel instability. For multi‑tenant or production infrastructure, even a non-exploitable robustness bug of this class is significant because it increases operational risk and the potential for outages.
• Ease of exploitation. The practical difficulty for an attacker depends on their ability to deliver non‑IP QMI packets into the qmi_wwan path. Where such an attack is easy (for example, a compromised local user, a malicious USB modem, or an untrusted physical device), patching must be prioritized. Where the environment does not expose QMI devices, the practical risk is lower.

---

Why Microsoft’s attestation approach matters (and its limits)​

Microsoft’s move to publish CSAF and VEX attestations improves transparency: machine-readable attestations let customers automate triage and quickly determine whether a named Microsoft product ships a particular vulnerable component. The trade-off Microsoft made was a phased rollout: starting with Azure Linux (because of its clear supply chain and high cloud-customer relevance) reduces the risk of false positives and eases initial implementation. However, the phased approach necessarily means there is a time window during which some Microsoft artifacts are not yet attested; absence of an attestation is not proof of absence. Monitor Microsoft’s VEX feed and MSRC CVE pages — Microsoft will update individual CVE mappings as it completes more product inventories.
Operationally, the best approach for enterprise customers is to treat Microsoft’s attestation as authoritative for the product it names (Azure Linux), and to run targeted verification and remediation on other Microsoft artifacts in their own environment rather than assuming safety by omission.

---

Action checklist for system owners (recommended prioritized steps)​

• Inventory quickly
• Identify Azure Linux VMs and WSL hosts in your environment.
• Search for qmi_wwan presence across your fleet using the lsmod/modinfo techniques above.
• Confirm and categorize
• For each item that reports qmi_wwan or a kernel config enabling QMI, mark it as in-scope for remediation.
• Patch or mitigate
• Apply vendor-provided kernel updates for Azure Linux or the distribution in question.
• For WSL, update to the latest Microsoft-published kernel (or build a patched custom kernel) and apply the kernel image to your WSL instances.
• For hosts that cannot be patched immediately, consider blacklisting qmi_wwan if WWAN functionality is not required.
• Monitor MSRC VEX and vendor advisories
• Microsoft has committed to publishing VEX/CSAF attestations and updating CVE product mappings; consume these feeds and sign up for vendor advisories to detect when Microsoft adds other products to the attestation list.
• Document and automate
• Record the specific kernel versions, package names, and remediation steps applied per artifact.
• Automate the detection of qmi_wwan presence and the verification of kernel versions so you can quickly triage future upstream fixes.

---

Caveats and unverifiable points (what we cannot know from public evidence)​

• Whether every Microsoft-distributed kernel image (for example every WSL release, every Azure Marketplace image, every internal appliance image) included or still includes the qmi_wwan driver at the time the vulnerability was disclosed — this cannot be deterministically proven from public information alone. Microsoft’s published VEX attestation covers Azure Linux; other artifacts must be verified locally or via Microsoft attestations when they are published. Treat lack of an attestation as unverified, not as unaffected. (msrc.microsoft.com)
• For WSL, while Microsoft publishes the kernel source tree and config templates, the exact configuration used in a specific shipped WSL kernel release may vary over time; operators must confirm the particular kernel version running on their host. The WSL repo provides the means to inspect and build the kernel, but the running binary on a given Windows client should be verified with uname -r and by inspecting the accompanying config shipped with that release.

These are not shortcomings of Microsoft’s transparency program — they are structural realities of any large vendor that ships many, sometimes highly customized, kernel builds. The correct operational stance is to combine vendor attestations with local artifact verification.

---

Bottom line​

• Short answer to your question: No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable qmi_wwan code. It is, however, the only Microsoft product Microsoft has publicly attested (so far) to include the implicated upstream component for CVE-2024-43861, and Microsoft has promised to update the VEX/CSAF mappings if additional Microsoft products are found to ship the component. (msrc.microsoft.com)
• Operational guidance: Treat Microsoft’s Azure Linux attestation as authoritative for Azure Linux images; for all other Microsoft artifacts (WSL kernels, Marketplace images, appliance images), perform the verification checklist above (lsmod / kernel config / package content) and patch or mitigate where qmi_wwan is present. Prioritize hosts that actually attach WWAN devices or allow untrusted local access.
• Security posture: This CVE is a robustness/memory-leak issue that can cause denial of service in the right conditions. The fix is straightforward and has been backported by multiple vendors; prioritize kernel updates where qmi_wwan is present and monitor Microsoft’s VEX/CSAF feed for additional attestations or product mapping updates.

By combining Microsoft’s published VEX attestations with focused, artifact-level verification and prompt kernel patching, organizations can close the practical exposure window for CVE-2024-43861 while waiting for additional vendor attestations to be published.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center