Microsoft has acknowledged that a recently patched Linux kernel vulnerability, tracked as CVE-2024-39484, exists within the Azure Linux distribution. But the carefully scoped wording of its advisory raises a pressing question for anyone managing Microsoft-shipped Linux kernels: do artifacts like the WSL2 kernel, Marketplace VM images, or container base images carry the same flaw? The short answer is that they very well might, and the only way to be sure is through per‑artifact verification.

The vulnerability at a glance

CVE-2024-39484 is a defect in the Linux kernel’s MMC DaVinci driver subsystem. The driver’s cleanup callback—the function that runs when a device is unbound—was marked with the kernel’s __exit attribute. When the driver is compiled directly into the kernel image rather than built as a loadable module, that attribute tells the build system to strip the function out entirely. The result: if a DaVinci MMC device is removed at runtime (via sysfs, hotplug, or similar), the kernel never runs the cleanup routine, leaving allocated memory, DMA mappings, and other resources hanging.

The upstream fix, which has been backported into stable kernel branches, simply removes the __exit annotation so the remove callback stays in the image regardless of configuration. The bug carries a CVSS score of 5.5, reflecting a medium‑severity availability impact—resource leaks can degrade stability and, on long‑running systems, open the door to denial‑of‑service conditions. It is not, on its own, a remote code execution or privilege escalation vector.

Microsoft’s advisory: what it says (and what it doesn’t)

In its Security Update Guide entry for CVE-2024-39484, Microsoft states plainly: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” That sentence is authoritative for the Azure Linux product family. It tells Azure Linux operators, unequivocally, that they are carrying the vulnerable code and must patch.

The company also explains, in a supporting FAQ, that it began publishing machine‑readable CSAF/VEX attestations in October 2025 as part of a broader transparency push, and that “if impact to additional products is identified, we will update the CVE to reflect this.”

This is where the operational nuance bites. The advisory scopes the confirmation to Azure Linux only. It does not state that no other Microsoft product ships the affected kernel driver. Absent an explicit attestation for, say, the WSL2 kernel or a curated Azure Marketplace VM image, security teams cannot assume those artifacts are unaffected. They are, as of this writing, unverified.

Why this matters for you: home users, admins, developers

If you run Azure Linux workloads
Your path is clear: apply the latest Azure Linux kernel updates immediately. Microsoft has confirmed you are carrying the vulnerable code. The fix has been incorporated into Azure Linux’s release stream; check your package manager or Azure Update Manager for the appropriate patches.

If you use Windows Subsystem for Linux 2
WSL2 distributions run on top of a Microsoft‑provided Linux kernel. That kernel is built from a tree that may or may not include the MMC DaVinci driver and, if it does, may or may not have the driver compiled in. Microsoft has not yet issued a VEX attestation for the WSL2 kernel in this CVE. Until it does, WSL2 users should inspect their running kernel to see if the driver is present. A quick way: from inside a WSL2 session, run zcat /proc/config.gz | grep CONFIG_MMC_DAVINCI (or check /proc/modules for davinci_mmc). If the flag is set, consider the kernel potentially affected and watch for an update from Microsoft.

If you rely on Azure Marketplace VM images or container base images
Many Marketplace images ship with Linux kernels that are not the standard Azure Linux kernel. The same goes for container base images provided by Microsoft. Each of these artifacts is built from a different kernel tree and may carry a different configuration. Until Microsoft publishes CSAF/VEX attestations for these specific artifacts—or until you inspect them yourself—treat them as “not yet confirmed safe.” Contact your Microsoft support representative if you need an authoritative statement for a particular image.

For developers and IT pros managing appliances
Some Microsoft appliances, firmware bundles, or managed services may embed a Linux kernel. If you cannot inspect the kernel directly (because the device is locked down), treat it as unverified and open a ticket with Microsoft to request an explicit VEX attestation for that artifact. Your maintenance agreement likely entitles you to that information.

How we got here: a timeline of transparency

  • Upstream discovery: The Linux kernel community identified the __exit misuse and committed the fix. It was backported to stable long‑term kernels, which many distributions consume.
  • Distribution tracking: Independent security trackers like CVE‑News and the Linux Kernel CVE Tracker cataloged CVE‑2024-39484 and linked it to the DaVinci driver. Vendors began rolling the patch.
  • Microsoft’s VEX rollout (October 2025): Microsoft started publishing CSAF/VEX documents for Azure Linux, promising machine‑readable, product‑scoped security advisories. This was a direct response to industry demand for better software supply chain transparency.
  • Current advisory: The MSRC entry for CVE-2024-39484 reflects that initial Azure Linux inventory. The FAQ explicitly acknowledges that the attestation may expand as Microsoft completes inventories of other products.

This gradual rollout explains why the advisory’s language feels both reassuring and incomplete. Microsoft has delivered on its promise for the product family it controls most tightly, but the broader inventory of every kernel‑bearing artifact it ships is still a work in progress.

What you must do now

  1. Patch Azure Linux without delay. Open your update manager or run tdnf update (on Mariner‑based Azure Linux 2.0) or apt update (on Azure Linux 3.0, which uses APT) to pull the patched kernel. Reboot the system after the update.

  2. Inventory other Microsoft‑shipped kernels in your environment. Make a list of every location where you run a Microsoft‑provided Linux kernel: WSL2 instances, custom VM images from the Azure Marketplace, container base images (mcr.microsoft.com), on‑premises appliances, and any managed service that might embed Linux.

  3. Inspect each artifact for the DaVinci driver.
    - For running systems: check kernel config (/proc/config.gz), look for the davinci_mmc module in /proc/modules, or scan for the driver source string in the kernel.
    - For offline images or packages: use tools like strings, sbomqs, or your organization’s SBOM scanner to search for the symbol davinci_mmc_driver or the presence of the driver file.
    - If the driver is absent, the artifact is not affected. If present, check whether the driver is built as a module (cleanup function is retained) or built‑in (cleanup function may be stripped—more analysis needed).

  4. Apply the upstream patch if you can rebuild. If you maintain your own kernel builds based on an affected Microsoft source tree, cherry‑pick the upstream commit (removing __exit from the remove function) and rebuild.

  5. For artifacts you cannot inspect or control: file a support request with Microsoft. Ask specifically for a CSAF/VEX attestation for the artifact in question under CVE-2024-39484. Until that attestation arrives, treat the artifact as “unknown” and restrict exposure where possible—disable hotplug operations that unbind MMC devices, or isolate the host from untrusted USB/thunderbolt devices that could trigger the path.

  6. Update your vulnerability management process. Incorporate VEX and SBOM ingestion into your CI/CD and patching pipelines. Microsoft’s machine‑readable attestations will only grow; having tooling that can automatically consume and cross‑reference them against your inventory will close blind spots at scale.

What to watch next

Microsoft’s move toward machine‑readable attestations is a significant improvement for the Linux supply chain. But the gap revealed by CVE-2024-39484—where an advisory stops at the most obvious product while leaving sibling artifacts unmentioned—is a structural one that will only be solved by broader VEX coverage. Expect Microsoft to publish additional attestations for the WSL2 kernel and curated images in the coming months as its internal inventory work progresses. In the meantime, treat every unattested Microsoft kernel as a prompt to verify. The days when a single “Azure Linux only” statement could cover your entire Microsoft‑based Linux estate are not quite here yet.