A kernel-level Thunderbolt bug tracked as CVE‑2025‑38174 — described upstream as "thunderbolt: Do not double dequeue a configuration request" — has been assigned after reports of kernel crashes caused by a double-dequeue operation in the Thunderbolt configuration request path. The immediate public evidence shows kernel oopses on versions built around Linux 6.6.65 and indicates the defect can cause general protection faults that take hosts offline; Microsoft’s Security Response Center (MSRC) has published a product‑scoped attestation naming Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that attestation is explicitly scoped and does not, by itself, prove that no other Microsoft product carries the same vulnerable code.
The vulnerability is located in the Linux kernel’s Thunderbolt subsystem and arises when a single configuration request can be scheduled and processed more than once. Two separate scheduling paths — one via a frame callback and another via a direct request path — can lead to the same worker executing a dequeue routine twice for the same request. The resulting double list_del() on the request queue can poison kernel list metadata and produce a non‑canonical pointer dereference; reported call traces include tb_cfg_request_dequeue and tb_cfg_request_work and point to general protection faults with a signature non‑canonical address (for example 0xdead000000000122 in observed crash logs).
Security trackers and distro advisories describe the problem consistently: the fix ensures that requests are not dequeued unless the TB_CFG_REQUEST_ACTIVE bit is set, and upstream kernel trees received targeted commits to avoid the double-dequeue race. Public vulnerability records date the CVE publication in early July 2025 and list the issue as a robustness/availability defect rather than an information‑disclosure or privilege‑escalation bug.
Key verifiable facts at time of writing:
What that does mean in practice:
Put plainly:
Two important caveats:
However, there are limitations:
Microsoft’s public line that “Azure Linux includes this open‑source library and is therefore potentially affected” is an authoritative attestation for that product family and should be acted upon by Azure Linux customers. But it is not an exclusivity statement — other Microsoft images that embed Linux kernels could also be carriers until specifically inventoried and attested. Customers should treat un‑attested artifacts as potentially affected, perform the kernel inventory checks described above, apply patches where available, or mitigate by disabling the Thunderbolt subsystem until patched.
Action summary (short):
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
The vulnerability is located in the Linux kernel’s Thunderbolt subsystem and arises when a single configuration request can be scheduled and processed more than once. Two separate scheduling paths — one via a frame callback and another via a direct request path — can lead to the same worker executing a dequeue routine twice for the same request. The resulting double list_del() on the request queue can poison kernel list metadata and produce a non‑canonical pointer dereference; reported call traces include tb_cfg_request_dequeue and tb_cfg_request_work and point to general protection faults with a signature non‑canonical address (for example 0xdead000000000122 in observed crash logs).Security trackers and distro advisories describe the problem consistently: the fix ensures that requests are not dequeued unless the TB_CFG_REQUEST_ACTIVE bit is set, and upstream kernel trees received targeted commits to avoid the double-dequeue race. Public vulnerability records date the CVE publication in early July 2025 and list the issue as a robustness/availability defect rather than an information‑disclosure or privilege‑escalation bug.
Key verifiable facts at time of writing:
- The fault has an upstream Linux kernel call trace observed on kernels around 6.6.65 and was fixed upstream with a change to tb_cfg_request_dequeue/work behavior.
- Several distro and vendor trackers (NVD, Debian, OSV, Rapid7, Wiz and others) have recorded the CVE and technical details; different advisories reflect vendor-specific patch timelines and statuses.
- At least one Linux advisory register (ALAS/AWS) reports a CVSS baseline around 5.5 (medium severity), reflecting the bug’s primary impact on availability (system crashes).
Why Microsoft named Azure Linux, and what that wording means
Microsoft’s public CVE entries for a number of Linux kernel CVEs — including the phrasing quoted by many customers — contain the same short FAQ: “Is Azure Linux the only Microsoft product that includes this open‑source library and is therefore potentially affected by this vulnerability?” Microsoft answers by describing Azure Linux as a distribution Microsoft keeps up to date, notes the company’s rollout of machine‑readable CSAF/VEX attestations (beginning in October 2025), and promises to update CVE mappings if additional Microsoft products are found to ship the component. That language is deliberate and product‑scoped.What that does mean in practice:
- Azure Linux = attested carrier. Microsoft has inspected and confirmed that Azure Linux images/kernels contain the upstream component(s) implicated by the CVE. Customers running Azure Linux therefore have a clear, supported remediation path and should plan to patch accordingly.
- Not an exclusivity guarantee. The MSRC wording is an inventory statement for a named product; it is not a technical proof that every other Microsoft image, build, or kernel artifact lacks the same upstream code. In other words, Azure Linux is the only Microsoft product publicly attested so far — but other Microsoft artifacts could still be carriers until they are inventoried and declared Not Affected or Fixed.
Technical analysis: how the bug is triggered and why it is dangerous
The double‑scheduling root cause
- The vulnerable pattern arises when the same configuration request object is scheduled for handling by two paths: once via a frame’s callback executed in ring_work(), and again via the tb_cfg_request() caller path. If both scheduling actions occur for the same logical request, two kernel worker threads may concurrently execute tb_cfg_request_dequeue(), leading to a double list_del() on the request queue. When linked-list nodes are removed twice, the kernel list infrastructure is corrupted and subsequent list or pointer accesses can dereference a poisoned/non‑canonical pointer — crash follows.
- Reported call traces on affected machines show the fault occurring in tb_cfg_request_dequeue and tb_cfg_request_work and terminate in worker_thread/kthread frames — symptoms consistent with a race and queue corruption. Observed machine states and poison markers (e.g., 0xdead... addresses) are classic indicators of list corruption.
Impact model
- Availability: Primary and immediate impact — the bug causes kernel oopses / general protection faults that crash or hang hosts, creating denial‑of‑service conditions. Public trackers classify the issue as medium severity (availability impact).
- Exploitability: The vulnerability is a robustness race and requires the right sequencing of Thunderbolt configuration operations; it is not described as allowing arbitrary code execution or privilege escalation. Attack complexity is therefore higher than many remote code vulnerabilities. However, in environments where untrusted Thunderbolt devices or complex hotplug patterns exist, the practical exposure can be meaningful.
- Scope of affected kernels: Any Linux kernel build that includes the Thunderbolt subsystem and ships a vulnerable commit range or lacks the upstream patch is potentially affected. That includes custom kernels, distribution kernels (including Azure Linux), vendor OEM kernels, and any Microsoft images that embed such kernels—until those images are inventory‑checked.
Is Azure Linux the only Microsoft product that includes the open‑source library? (short answer)
No — not necessarily. Microsoft’s published statement names Azure Linux as the product it has inspected and attested to contain the implicated upstream component; that attestation is authoritative for Azure Linux images Microsoft has checked. But because the vulnerable code lives in upstream Linux kernel source, any Microsoft product that ships a Linux kernel build configured to include the Thunderbolt subsystem and compiled from a vulnerable upstream commit range could also carry the issue. Until Microsoft expands its product mappings (MSRC/CSAF/VEX) to list additional products, you cannot assume those other artifacts are free of the code.Put plainly:
- Azure Linux = confirmed attested carrier. Patch it.
- Other Microsoft artifacts (WSL kernels, custom Azure VM images, Marketplace images, appliance kernels) = possibly carriers until Microsoft inventories and attests them one way or the other. Treat them as requiring verification.
How to verify exposure in Microsoft-supplied artifacts and in your estate
Follow these steps to build a defensible inventory and risk profile:- Identify kernel builds in use
- For each Microsoft image or artifact you run (Azure VM images, Marketplace appliances, WSL2 kernels, Azure Linux instances), capture the running kernel version and, when possible, the exact kernel package or build metadata.
- Use uname -a / rpm -q / dpkg -l / az vm image version metadata and record kernel compile IDs where available.
- Check for Thunderbolt subsystem presence
- Look for the thunderbolt subsystem modules and config: lsmod | grep thunderbolt, or check kernel config for CONFIG_THUNDERBOLT or related options. If the Thunderbolt subsystem is absent, the specific tb_cfg_request path is not present and the CVE’s impact is moot on that artifact.
- Cross‑reference upstream commit ranges
- When you have kernel build IDs, compare them to upstream fixes. Public advisories note that the crash traces were seen in kernels around 6.6.65; consult vendor advisories and your kernel vendor for exact patched versions. Use NVD/OSV/debian/Ubuntu advisories as a cross‑check.
- Use Microsoft CSAF/VEX and SBOMs where available
- Microsoft’s rollout of machine‑readable CSAF/VEX attestations for Azure Linux is intended to help customers automate inventory mapping. Check MSRC product pages and the published VEX/CSAF files for Azure Linux and, when Microsoft updates other product mappings, those product pages as well. Recognize that absence of an attestation for a product is not proof of absence of the vulnerable code — it is an absence of inventory evidence.
- When in doubt, assume potential exposure and treat as needing action
- For critical or production workloads, remediation planning should assume exposure if your kernel build includes the Thunderbolt subsystem and falls in the vulnerable commit range.
Practical mitigations and remediation guidance
- Patch first where possible. The most reliable mitigation is to apply the vendor‑supplied kernel updates that include the upstream fix. Azure Linux customers should apply the Azure Linux kernel updates provided via Microsoft’s channels; distro vendors (Debian, Ubuntu, Red Hat, Oracle) have likewise released kernel updates for their packages. Cross‑check the advisory status with vendor trackers and apply tested updates.
- Disable Thunderbolt hardware if not required. Where kernel updates are not immediately available, administrators can mitigate by disabling the Thunderbolt driver or disabling Thunderbolt support in firmware/BIOS for hosts that do not require hotplugged Thunderbolt devices. This avoids the vulnerable code path entirely.
- Restrict device attachment. Prevent untrusted physical device attach to hosts by enforcing physical access controls and using platform features that require device authorization (Thunderbolt security levels, authorized devices lists).
- Monitoring and detection. Look for kernel oopses referencing tb_cfg_request_dequeue or tb_cfg_request_work in dmesg/journalctl logs. Search for evidence of poisoned list pointers and non‑canonical addresses in crash dumps. While not a perfect early‑warning system, sudden kernel oopses in Thunderbolt-enabled hosts should be triaged against this CVE.
- Work with Microsoft to confirm image mappings. If you run Microsoft-provided artifacts beyond Azure Linux (for example WSL2 kernels distributed via Microsoft, Marketplace images, or specialized Azure service kernels), contact your Microsoft support or account team and request product‑scoped attestation or confirmation for those specific artifacts; MSRC has committed to update CVE product mappings if additional Microsoft products are discovered to be carriers.
Who should be most concerned
- Administrators of cloud VMs and bare‑metal hosts with Thunderbolt hardware exposed to untrusted device attach (e.g., shared lab machines, developer laptops in open spaces). The bug’s impact is availability — unexpected reboots and service interruption.
- Operators of custom kernel images and appliance vendors. If you build or distribute kernels that include the Thunderbolt subsystem and do not track upstream commits carefully, you may be carrying the vulnerable code without an explicit vendor advisory unless you, or your provider, performs inventory checks.
- Microsoft customers running Azure Linux images: apply the vendor-provided updates per MSRC guidance. Microsoft’s attestation that Azure Linux includes the relevant upstream code is a prompt to prioritize patching for that product family.
Verifying claims and the limits of public information
I verified the technical description and call traces with multiple independent sources: the National Vulnerability Database (NVD) entry for CVE‑2025‑38174, distro trackers (Debian/Ubuntu advisories), and open vulnerability repositories (OSV/Wiz/Rapid7). These sources consistently describe the tb_cfg_request_dequeue double‑dequeue theory and report observed kernel crash traces on kernels around 6.6.65; they also document vendor advisory statuses and recommended fixes.Two important caveats:
- Public CVE pages and vendor advisories can lag actual inventory work. Microsoft’s MSRC pages for many kernel CVEs use the same product‑scoped FAQ language, and Microsoft has stated its intention to publish CSAF/VEX attestations and to update product mappings when more products are identified. The MSRC wording is therefore an accurate record of the company’s inventory work to date, but it is not sufficient to conclude exclusivity.
- I cannot independently verify whether any given Microsoft product beyond Azure Linux currently contains the vulnerable commit without access to Microsoft internal build metadata or a published SBOM/VEX mapping for that product. Where public attestations are missing, the correct posture is to assume potential presence until proven otherwise, and to pursue verification through SBOM/VEX, vendor support channels, or controlled inspection of kernel builds. This limitation is a factual constraint, not an absence of diligence.
Recommended action checklist for IT teams
- For Azure Linux customers:
- Patch: Apply the Azure Linux kernel update that includes the upstream Thunderbolt fix as soon as Microsoft publishes it for your platform.
- Reboot scheduled workloads where necessary to ensure the patched kernel is active.
- Monitor boot and kernel logs for any residual oopses.
- For organizations running other Microsoft images/artifacts:
- Inventory: Record the exact kernel versions and build metadata for each Microsoft-provided image in use (including WSL2, Azure Marketplace VMs, device kernels).
- Query Microsoft/MSRC: Open a support case or consult MSRC product mappings to request confirmation of whether those artifacts include the implicated upstream kernel code.
- If confirmation is not timely, treat images as potentially affected and plan remediation options (patch, kernel replacement, or disabling Thunderbolt).
- For on‑premises and OEM devices:
- Check your firmware/BIOS options to disable Thunderbolt if not needed.
- Coordinate with hardware vendors for firmware updates that harden device authorization settings.
- For security teams:
- Add detection rules to search host logs for tb_cfg*request** traces.
- Prioritize systems with exposed or frequently changed Thunderbolt device connections.
Strengths and limitations of Microsoft’s attestation approach
Microsoft’s approach — publishing product-scoped CSAF/VEX attestations beginning with Azure Linux — is a meaningful positive step for transparency and automation. Machine‑readable attestations make it easier for automated vulnerability management systems to ingest vendor mappings and to focus patching efforts on the images Microsoft has confirmed contain the vulnerable component. That is a clear benefit to Azure Linux customers and to organizations that rely on Microsoft as an upstream.However, there are limitations:
- A product‑scoped attestation is necessarily partial until all product families are inventoried. Customers running diverse Microsoft artifacts must not substitute a single attestation for a comprehensive artifact‑level SBOM. The MSRC phrasing explicitly acknowledges this gap and promises updates as Microsoft’s inventory work continues.
- The cadence of VEX/CSAF updates matters. For organizations that require immediate certainty, the absence of an attestation for a specific image is insufficient to conclude safety — you need either a firm vendor declaration or an independent inventory of the image’s kernel build.
Final analysis and takeaways
CVE‑2025‑38174 is a kernel robustness defect in the Linux Thunderbolt subsystem that causes availability failures via a double‑dequeue/list corruption pattern. Public technical records (NVD, distro advisories, OSV, Rapid7, Wiz) document the call traces and the upstream fix approach; distribution vendors have published status and remediation guidance.Microsoft’s public line that “Azure Linux includes this open‑source library and is therefore potentially affected” is an authoritative attestation for that product family and should be acted upon by Azure Linux customers. But it is not an exclusivity statement — other Microsoft images that embed Linux kernels could also be carriers until specifically inventoried and attested. Customers should treat un‑attested artifacts as potentially affected, perform the kernel inventory checks described above, apply patches where available, or mitigate by disabling the Thunderbolt subsystem until patched.
Action summary (short):
- If you run Azure Linux: prioritize the vendor updates Microsoft publishes for the kernel.
- If you run other Microsoft images: inventory kernels, request MSRC/VEX/SBOM confirmation, and assume possible exposure until proven otherwise.
- If you manage devices with Thunderbolt hardware and cannot patch immediately: consider disabling Thunderbolt or enforcing strict device authorization.
Source: MSRC Security Update Guide - Microsoft Security Response Center
