Microsoft has confirmed that its Azure Linux distribution is affected by a newly disclosed kernel vulnerability in the Linux Thunderbolt subsystem, which can cause sudden system crashes and denial-of-service conditions. The flaw, tracked as CVE-2025-38174, triggers a double-dequeue operation that corrupts kernel memory, leading to general protection faults and host outages. The company is urging Azure Linux customers to apply updates immediately, while also acknowledging that other Microsoft products may carry the same vulnerable code.

What happened: A race condition in the Thunderbolt driver

At the heart of CVE-2025-38174 is a race condition in the Linux kernel’s Thunderbolt configuration request handling. When a Thunderbolt device is connected or reconnected, the kernel schedules a configuration request. Due to a flaw, the same request can be scheduled twice—once through a frame callback and again via a direct request path. When two kernel worker threads attempt to process the identical request, they both execute a dequeue routine that removes the request from a linked list. The second removal corrupts the list, poisoning kernel metadata with a non-canonical pointer (such as 0xdead000000000122), which causes an instant general protection fault and system crash.

The bug manifests in kernel logs as a call trace pointing to tb_cfg_request_dequeue and tb_cfg_request_work, with crash signatures observed on Linux kernel versions around 6.6.65. The upstream fix ensures that a request is not dequeued unless a specific active flag (TB_CFG_REQUEST_ACTIVE) is set, preventing the double removal. Public vulnerability records, including those from NVD, Debian, and other distro trackers, rate the issue as medium severity, primarily impacting system availability. The CVE was published in early July 2025, and multiple Linux distributors have already released patched kernels.

Who is affected and how serious it is

Microsoft’s Security Response Center (MSRC) has posted an advisory that specifically attests Azure Linux as a product that “includes this open-source library and is therefore potentially affected.” That means Azure Linux instances—whether running on virtual machines or bare-metal—are confirmed carriers of the vulnerable code. For administrators of those systems, the risk is real: an attacker with physical access to a Thunderbolt port, or in some scenarios a malicious Thunderbolt device, could trigger a crash, disrupting services or causing repeated outages.

The broader concern is that the vulnerable code originates in the upstream Linux kernel, so any Microsoft product that ships a Linux kernel built from a vulnerable commit range could also be exposed. This includes Windows Subsystem for Linux 2 (WSL2) kernels, custom Azure Marketplace images, and specialized appliance kernels. Microsoft’s advisory does not yet rule out those artifacts; it only confirms Azure Linux as a known carrier. As Microsoft’s own FAQ states, “If impact to additional products is identified, we will update the CVE to reflect this.” Until then, administrators running other Microsoft-supplied Linux kernels should treat them as potentially vulnerable.

For the wider Linux ecosystem, any distribution or custom kernel that includes the Thunderbolt subsystem (CONFIG_THUNDERBOLT) and hasn’t backported the fix is susceptible. The impact is limited to availability—no privilege escalation or remote code execution is known—but for cloud workloads and critical servers, unexpected crashes can be highly disruptive.

How we got here: The discovery and disclosure timeline

The vulnerability was uncovered through upstream kernel testing and crash reports. A patch landed in the mainline Linux kernel to prevent the double dequeue, and major distributions like Debian, Ubuntu, and Red Hat quickly incorporated it into their kernel updates. Microsoft, which bases Azure Linux on upstream kernels, needed to respond both to the vulnerability and to the transparency requirements of its enterprise customers.

In October 2025, Microsoft began publishing machine-readable CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) documents for Azure Linux, aiming to give automated vulnerability scanners a clear picture of which components are affected. The advisory for CVE-2025-38174 is part of that transparency effort. However, the company’s product-scoped attestation has raised questions because it doesn’t yet cover every Microsoft image that might embed a Linux kernel.

What you should do now

If you run Azure Linux

  • Apply the vendor update immediately. Microsoft will release a patched Azure Linux kernel; check your regular update channels and install it. Reboot instances as needed to load the new kernel.
  • Monitor system logs for any residual tb_cfg_request_dequeue traces after the update. While the patch prevents the double dequeue, monitoring helps confirm nothing slipped through.

If you run other Microsoft-supplied Linux images

  • Inventory your kernels. Use uname -a and package manager queries (rpm -q or dpkg -l) to record exact kernel versions for all running instances.
  • Check for the Thunderbolt subsystem. Run lsmod | grep thunderbolt; if the module isn’t loaded and the kernel config doesn’t include CONFIG_THUNDERBOLT, that image is not affected. Otherwise, proceed with caution.
  • Contact Microsoft support or consult MSRC. Open a support case to ask whether your specific image (WSL2 kernel, Marketplace VM, etc.) has been inventoried. If official confirmation is slow, assume the kernel is vulnerable until proven otherwise.
  • Plan mitigation. If you can’t patch immediately, consider disabling Thunderbolt in the host’s firmware/BIOS, or restrict physical USB-C/Thunderbolt port access. In virtualized environments, ensure that Thunderbolt passthrough is not enabled for untrusted devices.

For all Linux administrators

  • Update to the latest distro kernel that includes the fix. Check your distribution’s security advisory for the patched version number.
  • Disable Thunderbolt support if not needed. On physical hosts, access BIOS/UEFI settings and turn off Thunderbolt entirely, or set Thunderbolt security to “user authorization” or “secure connect” so that new devices are not auto-connected.
  • Add detection rules. Look for kernel oopses containing tb_cfg_request_dequeue or tb_cfg_request_work in dmesg or journalctl. Crash dumps that contain non-canonical addresses (like 0xdead...) are a strong indicator.

What’s next: Microsoft’s transparency push and future patches

Microsoft has committed to expanding its CSAF/VEX program to give customers automated, machine-readable attestations for Azure Linux and eventually for other products. This will make it easier for vulnerability management tools to pinpoint exactly which images are affected by kernel CVEs, reducing guesswork. In the meantime, the company says it will update product mappings for CVE-2025-38174 if additional Microsoft products are found to carry the vulnerable code.

The episode underscores a broader challenge: tracking upstream Linux kernel vulnerabilities across a diverse fleet of cloud images, virtual appliances, and developer tools. As Microsoft and other vendors improve their SBOM (Software Bill of Materials) coverage, administrators should still maintain their own kernel inventories and not rely solely on vendor statements that may be incomplete. For now, if you use any Microsoft Linux offering beyond Azure Linux, verify before you trust.