On June 10, 2025, Microsoft published a security advisory for a Linux kernel flaw, CVE-2025-38153. The notice read exactly as many others have this year: “Azure Linux includes this open-source library and is therefore potentially affected.” For system administrators running Azure Linux, the message was clear—patch immediately. But for a much larger audience of Windows users who rely on Microsoft’s own WSL2 kernel, or for IT teams managing a zoo of Azure Marketplace images, the advisory raised more questions than it answered. Does this bug affect only Azure Linux, or could other Microsoft-supplied kernels be vulnerable? The answer, as we’ll explain, is not nearly as comforting as the brevity of the statement suggests.

A Coding Slip-Up with Big Consequences

CVE-2025-38153 resides in the Linux kernel driver for the AQC111 family of USB Ethernet adapters. The error is subtle: the USB networking helper (usbnet) can occasionally return fewer bytes than requested, and the aqc111 driver failed to verify that it had read all expected data before proceeding. In practice, this left the driver working with partially uninitialized memory—potentially corrupting MAC addresses or triggering kernel sanitizer warnings like KMSAN.

The impact is not typically remote code execution; an attacker needs some way to prod the driver, such as connecting a malicious USB Ethernet dongle, or by already having local access to the system. In many environments, that reduces the immediate blast radius. But in cloud or virtualized settings—precisely where so many Microsoft-supplied kernels run—a tenacious adversary could leverage device pass-through or emulation to exploit the flaw. The upstream Linux community classified the issue as medium-high severity, with availability and memory safety at stake, and committed patches to stable kernel trees starting in late May 2025.

Microsoft’s Cryptic Advisory Under the Microscope

Microsoft’s statement for CVE-2025-38153 is part of a new approach to vulnerability disclosure: machine-readable attestations via the Common Security Advisory Framework (CSAF) and the Vulnerability Exploitability eXchange (VEX). Since early 2025, the Microsoft Security Response Center (MSRC) has been rolling out these attestations, beginning with Azure Linux as the initial target. The aim is to provide a clear inventory of affected components on a per-product basis.

For Azure Linux, the phrase “includes this open-source library and is therefore potentially affected” serves as a definitive confirmation—Microsoft inspected Azure Linux builds, found the vulnerable aqc111 source code, and flagged it. That’s helpful, but it also illustrates a crucial limitation: the absence of any other product in the advisory does not mean those products are clean. As Microsoft itself acknowledges, the CSAF/VEX program is being expanded product-by-product. Until a product appears in the advisory, it simply hasn’t been attested one way or the other.

The practical consequence is that all other Microsoft-distributed Linux kernels—from the WSL2 kernel shipping with Windows 11 to the linux-azure kernels used by certain Azure VMs—must be treated as potentially vulnerable until verified. Microsoft did not say “only Azure Linux is affected”; it only said “Azure Linux is affected.” There’s a world of difference.

Is Your Windows Machine at Risk?

If you use Windows Subsystem for Linux 2 on your desktop or server, the kernel you run is a custom Linux kernel compiled by Microsoft. It sits in a separate package, typically updated via Windows Update, and while Microsoft publishes the source code, the prebuilt binary might include a wide range of drivers. The aqc111 module could have been compiled into that kernel or left as a loadable module, depending on the build configuration at the time.

For most home users, the real-world risk is low: you’d need to have WSL2 active, the aqc111 driver loaded, and a malicious USB Ethernet device attached—or a virtual one presented through hypervisor magic. But for power users and developers who experiment with USB passthrough in WSL2, or for IT pros who deploy Windows workstations with WSL2 enabled, it’s not an academic concern. A kernel panic triggered by a buggy driver can disrupt work and, in worst cases, be used as part of a denial-of-service chain.

The same logic applies to any Microsoft-supplied Linux kernel running in Azure: if you’re using an Azure Marketplace image that bundles a Microsoft-built kernel, or if you run AKS node pools built from Azure Linux (formerly CBL-Mariner), the aqc111 module might be present and loadable. The attack surface expands if your cloud environment allows attaching virtual USB devices—a feature some nested virtualization setups support.

How We Got Here: A Timeline

  • Mid-May 2025: Linux kernel maintainers discover the flawed byte-count validation in the aqc111 driver and begin crafting a fix.
  • Late May 2025: Patches are committed to the mainline kernel and backported to stable kernel versions (e.g., 5.15.x, 6.1.x, 6.6.x). The commit IDs and backport details are published in the usual kernel mailing lists and git repositories.
  • June 3, 2025: CVE-2025-38153 is reserved and posted to the CVE list. Independent vulnerability trackers and Linux distribution security teams start mapping the bug to their package versions.
  • June 10, 2025: Microsoft releases its advisory through the MSRC Security Update Guide, stating Azure Linux is potentially affected. The advisory mentions the aqc111 open-source library and links to the upstream fix, but names no other products.

This timeline underscores a common tension in open-source supply-chain security: upstream fixes move fast, but downstream inventory and communication can lag. Microsoft’s transparent, phased approach is an improvement over silence, but it also means customers must actively monitor and cross-check.

What You Should Do Right Now

Your action plan depends on what you run.

If You Manage Azure Linux VMs or AKS Nodes

  • Patch immediately. Follow Microsoft’s guidance for Azure Linux: apply the recommended kernel update. For AKS node images, consult Azure Kubernetes Service documentation; Microsoft expects to deliver updated node images shortly after the advisory.
  • Verify the fix. After updating, check the kernel package version against the patched versions listed by Microsoft or in the upstream advisories. Use uname -r and the package manager.

If You Use WSL2 on Windows 10 or 11

  • Check your WSL kernel version. Open a WSL terminal and run uname -r. Compare it to the latest WSL kernel available from Microsoft. As of the advisory date, the latest stable WSL kernel provided by Microsoft is 5.15.x, but check the official release notes.
  • Look for the aqc111 module. Run modinfo aqc111. If the module is present, it could potentially be loaded if a USB Ethernet device is attached. If you don’t need USB Ethernet inside WSL2, consider blacklisting it by creating a file in /etc/modprobe.d/ with blacklist aqc111. However, note that the WSL2 kernel is not typical: it’s tightly integrated with the Windows host and often doesn’t support arbitrary module loading from userspace. Still, checking is worthwhile.
  • Update your WSL kernel. If a new kernel is available that includes the fix, download and install it. WSL kernels can be updated via Windows Update or manually from the WSL GitHub releases page.
  • If you can’t update, mitigate. Avoid using USB passthrough in WSL2, especially with untrusted devices. Disable USB pass-through features if not required.

If You Run Other Microsoft-Supplied Kernels in Azure or On-Premises

  • Inventory everything. Create a list of all Linux kernels you use that came from Microsoft: Azure Marketplace images, linux-azure kernel packages on Azure VMs, custom images derived from Azure Linux, and any appliance kernels.
  • Probe for aqc111. For each system, check modinfo aqc111 or search /lib/modules/*/ for the driver. Also examine the kernel build config: if CONFIG_USB_NET_AQC111 is not set or is set to ‘n’, the driver isn’t compiled.
  • Map kernel versions to patches. Use public trackers (like the Linux kernel git log or distribution advisories) to see if your kernel’s commit history includes the fix. If you have source, you can grep for the patch commit ID.
  • Blacklist if necessary. On critical servers where patching is delayed, add blacklist aqc111 to /etc/modprobe.d/ and unload it if loaded. But be aware that server environments rarely need USB Ethernet drivers, so the module may already be dormant.
  • Monitor for updates. Microsoft may expand its advisory to name additional products. Subscribe to MSRC notifications or watch the CSAF/VEX feed for changes to CVE-2025-38153.

For All Users

  • Don’t rely solely on scanner plugins. While vulnerability scanners will pick up on the CVE ID, they often report based on package version matching. Verify the actual module presence and runtime exposure if possible.

The Road Ahead

Microsoft’s pivot toward structured attestations with CSAF and VEX is a positive step for security transparency. The company has promised to widen the net beyond Azure Linux, and as it does, advisories like this one will become more actionable for the full range of its customers. In the meantime, the responsibility falls on IT teams and power users to connect the dots. CVE-2025-38153 is a mirror held up to the often-messy reality of kernel-level supply-chain risk: a single driver buried in the source tree can affect dozens of downstream artifacts, and vendor communications rarely capture the whole picture in one go.

The advice from security experts is consistent: treat un-attested products as unverified, not immune. Patch what you can confirm is affected, inventory what you can’t, and keep an ear to the ground. With kernel bugs, the difference between a stable system and a cryptic crash can be one overlooked driver.