Microsoft has formally acknowledged that its Azure Linux distribution ships with a vulnerable component tied to CVE-2025-23157, a bug in the Linux kernel’s Qualcomm Venus video driver that could allow an attacker with local access to crash the system. The company’s security advisory stops short of naming any other Microsoft product as affected, leaving users of WSL2, Azure-tuned kernels, and other Microsoft-delivered Linux images to determine their own exposure.
A Kernel Flaw with Limited Exploitability, but Broad Linux Reach
CVE-2025-23157 is an out-of-bounds read in the Host Firmware Interface (HFI) parser of the Qualcomm Venus video driver. By sending repeated or malformed firmware payloads, an attacker can cause a codec counter to overflow, triggering a kernel read beyond a buffer’s boundary. The immediate risk is denial of service—a system crash—not remote code execution, and exploitation requires local access to a device where the driver is loaded. Public severity scores place the vulnerability in the low-to-medium range.
But the driver gets compiled into many Linux kernels, not just those running on Qualcomm hardware. Kernel configs often include it as a module, meaning it’s present in the build, even if it never activates. That’s why Microsoft’s admission matters: if one Microsoft-distributed kernel contains the code, others might too, and the absence of a public statement doesn’t equal safety.
Upstream Linux maintainers patched the flaw earlier this year, and patches have since filtered into distribution updates. The vulnerability is tracked across NVD, OSV, and vendor advisories, with affected kernel ranges and fixed commits well-documented.
Microsoft’s Advisory: Azure Linux Confirmed, Everything Else Unknown
On its Security Update Guide page for CVE-2025-23157, Microsoft responded to a direct question: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?” The reply sidesteps a simple yes or no:
One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries with which the distro is composed. Microsoft is committed to transparency in this work which is why we began publishing CSAF/VEX in October 2025. See this blog post for more information. If impact to additional products is identified, we will update the CVE to reflect this.
The language is careful. Azure Linux is explicitly named, so customers there know they are affected and must patch. For every other Microsoft-shipped Linux kernel—WSL2, the linux-azure cloud kernels, container host images, and marketplace artifacts—the advisory offers no verdict. Microsoft promises to extend the CVE mapping if it later finds those products also include the vulnerable library, but for now, they remain unverified.
That puts the verification burden on the user. The advisory’s phrasing is a product-scoped inventory statement, not a guarantee that only Azure Linux is impacted. Anyone operating other Microsoft kernels should treat them as potentially vulnerable until proven otherwise.
What This Means for You, Depending on Your Setup
If you run Azure Linux virtual machines or services
You are in the confirmed blast radius. Microsoft’s attestation means the vulnerable code is there. Patch immediately following the MSRC guidance, and consume the CSAF/VEX data to automate tracking. Distributions that package the Azure Linux kernel have likely already shipped updates; check your package manager or cloud provider for specific kernel versions.
If you use WSL2 on Windows 10 or Windows 11
Your WSL2 instance runs a Microsoft-built Linux kernel, distributed through Windows Update or as a standalone .msi installer. That kernel may include the Venus driver—it depends on the kernel version and the build configuration Microsoft used. For example, the linux-msft-wsl-6.6.36.3 tag and its modules.vhdx could contain the driver, but you must inspect the actual build to know. Even if you aren’t running Qualcomm hardware inside WSL, the driver could still be present as a loadable module, and a local attacker inside the WSL environment could trigger it.
If you use Linux images from the Azure Marketplace or other Microsoft-published cloud kernels
Images labeled “linux-azure” or otherwise optimized for Azure often ship kernels tuned by Microsoft. These kernels frequently incorporate upstream drivers. Even if the base distribution is Ubuntu, Red Hat, or SUSE, the cloud-specific kernel package may inherit the Venus code. Check the vendor advisory for that specific kernel flavor, not just the distro’s generic kernel.
If you’re an IT administrator managing mixed environments
Inventory every Microsoft-supplied Linux artifact in your estate—Azure Linux VMs, WSL2 instances, container host nodes, IoT devices, and specialized appliances. Assume any of them could be affected until you’ve verified each one. This isn’t a panic-level vulnerability, but unpatched kernels that can be crashed locally erode defense-in-depth and complicate incident response.
How the Vulnerability Was Disclosed and Patched
The timeline is routine for Linux kernel security. Maintainers of the Qualcomm Venus driver discovered the parsing flaw and submitted a fix to the upstream kernel, which landed in a stable release. Distribution maintainers then backported the patch into their supported kernel versions. The CVE assignment and public advisories followed.
Microsoft’s involvement is notable because of its newer transparency push. Since October 2025, the company has published CSAF/VEX documents for products that incorporate open-source components, joining a broader industry move toward machine-readable vulnerability disclosures. The CVE-2025-23157 listing is one of the earlier tests of that commitment. The advisory’s wording reflects the reality that Microsoft may not always have a complete picture of every artifact that reuses an open-source library—or even every artifact it ships. This is not unique to Microsoft; most large cloud providers struggle with the same inventory problem.
For WSL2 specifically, Microsoft maintains its own kernel fork and publishes source code on GitHub, but it does not routinely issue VEX documents for the WSL kernel. That means the certainty Azure Linux customers enjoy does not extend to WSL2 users. Without an attestation, you are left with manual verification.
What to Do Right Now
1. Azure Linux users: Patch immediately
- Apply the Azure Linux kernel update that addresses CVE-2025-23157. If you use Azure’s managed images, the update may already be available through normal update channels.
- Consume the MSRC CSAF/VEX feed to confirm the fix and track future updates.
2. WSL2 users: Check your kernel version and modules
- Open a WSL terminal and run uname -r. Note the kernel release string (e.g., 5.15.167.4-microsoft-standard-WSL2).
- Compare it against the affected range for CVE-2025-23157. Public databases like NVD list the ranges, but a simpler check: if your kernel version is older than the one that carries the fix, it’s potentially vulnerable.
- Next, check if the Venus driver actually exists in your modules. Run:
ls /lib/modules/$(uname -r)/kernel/drivers/media/platform/qcom/venus/
If the directory contains .ko files, the driver is present and could be loaded. Even if it’s not loaded by default, an attacker with sufficient privileges could load it.
- On systems where the kernel config is exposed (some WSL builds), run:
zcat /proc/config.gz | grep VENUS or grep VENUS /boot/config-$(uname -r)
If the config shows CONFIG_VIDEO_QCOM_VENUS=m or =y, the driver is included.
- For WSL2, Microsoft distributes modules inside a modules.vhdx file. Mount it and verify its contents for the same path.
- If you confirm the driver is present and your kernel is unpatched, update your WSL kernel. The easiest method for most users is to check for Windows updates—WSL kernel updates often arrive via Windows Update. Alternatively, download the latest WSL kernel .msi from Microsoft’s GitHub releases and install it.
3. Cloud and marketplace image operators: Verify your kernel packages
- For Azure-tuned kernels (e.g., linux-image-azure), check the distribution’s advisory. Ubuntu, for example, publishes CVE trackers that list specific package versions that contain the fix. Match those against your running kernel.
- If you build custom images, ensure your kernel source tree contains the upstream patch (commit hash is publicly available) and rebuild.
4. General enterprise hygiene
- Inventory all hosts running Microsoft-shipped Linux kernels. Use automated tools to query kernel versions and module lists at scale.
- Subscribe to MSRC notifications for CVE updates. If Microsoft later adds WSL2 or other products to the CVE mapping, you’ll be notified.
- If you can’t patch immediately, limit local user access and consider blocking loading of the venus module with kernel lockdown or module blacklisting (modprobe -r venus may not be sufficient if built-in). The risk is minimal for most environments, but it’s a low-effort hardening step.
The Bigger Picture: Microsoft’s Growing Transparency
Microsoft’s willingness to publicly state a product is affected—even when that product is its own distribution—is a sign of the industry’s evolving vulnerability disclosure culture. The CSAF/VEX program is still new; by acknowledging gaps in inventory completeness, Microsoft is being honest about the limitations of software supply chain tracking.
For users, the lesson is clear: when a kernel vulnerability surfaces, never assume that a vendor’s initial advisory covers all the binaries you run. The same open-source code can end up in dozens of packaging channels. Until vendors expand their VEX attestations to every product line, manual verification remains a necessary part of incident response.
Expect Microsoft to update the CVE-2025-23157 record if it identifies additional affected products. Keep an eye on the MSRC page and the CSAF feed. In the meantime, treat the Azure Linux confirmation as a starting point, not the final word, and complete your own audit of every Linux kernel you run from Microsoft.