CVE-2025-37812: Azure Linux and cdns3 Deadlock Patch Explained

The Linux kernel entry for CVE-2025-37812 — described as "usb: cdns3: Fix deadlock when using NCM gadget" — is now public, and Microsoft’s MSRC entry for the CVE states that Azure Linux includes this open‑source library and is therefore potentially affected; however, that MSRC attestation is a product‑level inventory statement, not proof that Azure Linux is the only Microsoft product that could contain the vulnerable code. ([msrc.microsoft.csoft.com/update-guide/vulnerability/CVE-2025-37812/))

---

Background / Overview​

CVE-2025-37812 is a concurrency/deadlock defect in the Cadence cdns3 USB driver in the Linux kernel. Under PREEMPT_RT (the real‑time kernel preemption configuration), the defect is readily triggerable by heavy bidirectional network traffic when the driver is used in its NCM gadget role (Network Control Model — i.e., when the device acts as a network interface to a host). The deadlock comes from the threaded interrupt handler being preempted by a softirq while both the threaded handler and the softirq paths use the same spinlock; upstream maintainers addressed the bug by ensuring softirq is disabled while the threaded IRQ handler runs.
Multiple Linux distribution trackers and vendor advisories catalog the same technical summary and list the affected kernel branches and stable backports where fixes were applied. Debian/Ubuntu trackers and vendor advisories (including Red Hat and Amazon Linux advisories) show patches and release mappings for the fix, confirming the upstream commit(s) were merged into the relevant stable trees. This cross‑vendor corroboration establishes the technical details and remediation path.
Why this matters operationally: unlike a userland library that is included exactly the same way across products, kernel code is a build‑time artifact. Whether a given system is affected depends on:

• the kernel version and whether the upstream fix has been merged into that release,
• the kernel configuration used when the kernel was built (the driver may be built-in, modular, or excluded),
• and runtime configuration (whether the gadget functions are enabled and whether PREEMPT_RT is in use).

That variability is the reason a single product attestation for Azure Linux tells customers which of Microsoft’s images were found to include the vulnerable code, but it cannot, by itself, prove that other Microsoft artifacts do or do not contain the same kernel component.

---

What Microsoft actually said — and how to read it​

Microsoft’s short FAQ language that you quoted — effectively: “Azure Linux includes this open‑source library and is therefore potentially affected” — is deliberately scoped. Microsoft has publicly committed to publishing machine‑readable CSAF/VEX attestations (starting with Azure Linux in October 2025) and to updating CVE product mappings if additional Microsoft products are identified as carriers for a given upstream component. That procedural commitment is important, but it does not mean other Microsoft products are guaranteed clean. It simply means: for now, Azure Linux is the Microsoft product the company has inventory‑checked and declared potentially affected. (msrc.microsoft.com)
Operationally, multiple independent explainers and internal analyses reinforce this reading: a product‑level attestation is an authoritative "yes" for that product, coupled with a promise to expand coverage as further inventories complete. Security teams should treat that attestation as actionable for Azure Linux images while continuing to verify other Microsoft‑supplied artifacts on a per‑artifact basis.

---

Short answer to the question​

• No — Azure Linux is not necessarily the only Microsoft product that could include the cdns3 gadget code and therefore be affected by CVE‑2025‑37812.
• Yes — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the implicated open‑source component for this CVE. Microsoft will update the official CVE/VEX mapping if other Microsoft products are later found to ship the same code.

Put simply: Microsoft’s statement is an authoritative, product‑scoped inventory result for Azure Linux — valuable and actionable for Azure Linux customers — but it is not an exclusivity guarantee that other Microsoft artifacts cannot carry the vulnerable kernel code.

---

How this can practically affect other Microsoft products​

Because the cdns3 gadget code is part of mainline Linux (drivers/usb/cdns3), any Microsoft product or image that ships a Linux kernel built with the cdns3 gadget enabled — or that attaches a kernel module for cdns3 to its images — could, in principle, include the vulnerable code until it is patched. Examples of Microsoft artifacts that might warrant verification include:

• Azure Marketplace VM images and Azure‑provided kernels.
• Azure Kubernetes Service (AKS) node images that use Azure Linux kernels or kernels derived from the same source.
• Microsoft‑maintained kernels for container hosts or specialized images (for example, certain Azure Linux container host builds).

You should not assume absence of a Microsoft attestation equals absence of risk for other Microsoft artifacts. Instead, treat the MSRC attestation as the starting point for focused inventory and verification across other Microsoft‑supplied images you depend on.

---

How to verify whether a given system or Microsoft artifact is affected​

Below are practical checks for administrators and build engineers. These steps assume you have access to the running system or the kernel artifacts you need to inspect.

• Check whether the cdns3 module is present or loaded on a running Linux system:
• lsmod | grep cdns3
• modinfo cdns3
  These commands reveal whether the cdns3 driver exists as a module and, if so, the module version and build information.
• Inspect the kernel configuration used to build the running kernel:
• zgrep CONFIG_USB_CDNS3 /proc/config.gz
• grep CONFIG_USB_CDNS3 /boot/config-$(uname -r)
  The driver is typically exposed by the Kconfig symbol CONFIG_USB_CDNS3, and the gadget variant as CONFIG_USB_CDNS3_GADGET. Confirming those options tells you whether the kernel was built with the driver and gadget support.
• If you have a kernel binary or an image file (for example, a Microsoft‑provided kernel blob), examine its build metadata or the .config used to build it. If you maintain SBOMs or CSAF/VEX manifests for images, ingest Microsoft’s VEX/CSAF attestations for Azure Linux and any other available product VEX files to speed mapping.
• Reproduce the affected configuration in a lab (carefully): the vulnerability is specifically problematic under PREEMPT_RT with NCM gadget usage. If your workload does not enable the NCM gadget or does not use PREEMPT_RT, your exposure is materially reduced — but you should still treat this as an item to verify because kernel artifacts and runtime roles can change over time.

---

Mitigation and remediation recommendations​

• Apply vendor patches immediately where available. Upstream kernels include the fix; distribution vendors and cloud providers will publish patched kernel packages — install those updates on affected images. Multiple vendor advisories and distribution trackers list fixed kernel versions and backports; use those mappings to determine which release you must patch to.
• If you cannot update immediately, consider temporary mitigations:
• Avoid enabling the NCM gadget role on affected devices.
• If cdns3 is delivered as a module, remove or blacklist the module until a patched kernel is available (understand the impact to any dependent functionality).
• Disable PREEMPT_RT on nodes where it is not required; the defect is specifically triggered under PREEMPT_RT. That said, changing preemption configurations on production systems may be disruptive — evaluate stability and performance tradeoffs carefully.
• For build engineers: rebuild kernels with the upstream fix applied or reconfigure kernel builds to exclude the gadget component if it is not required for your devices.
• For cloud operators and image maintainers: reconcile Microsoft VEX/CSAF attestations with your internal SBOMs and image inventories. If you ship Microsoft‑derived images (for example, for customers or internal services), verify whether those images include the vulnerable kernel builds and plan synchronized updates.

These steps are consistent with upstream patches that address the lock ordering by disabling softirq processing in the threaded IRQ handler, and with distribution vendor guidance that maps fixed commits into stable kernel releases.

---

A caution on exploitability and risk ranking​

• Impact model: the primary impact is availability — the issue causes a deadlock that can hang the kernel, effectively producing a denial‑of‑service. The upstream and distributor trackers characterize it as an operational availability defect rather than a confidentiality or integrity issue.
• Trigger complexity: the bug is easiest to trigger under PREEMPT_RT with high bidirectional network load over an NCM link (the iperf example is repeatedly used in advisories). That means many general-purpose servers or VMs — which do not enable the gadget role or PREEMPT_RT — are unlikely to be exploitable in ordinary configurations. Devices and images that deliberately enable USB gadget functionality (embedded devices, development boards, certain IoT images, or device firmware doing USB Ethernet) are the higher‑risk class.
• Exploitability in the wild: as of the time this advisory was recorded, public exploit reports were absent. That does not change patch priorities for affected systems, but it does influence immediate threat severity for general‑purpose cloud VMs that do not enable gadget functionality. Always triage based on your specific exposure model.

---

Why Azure Linux shows up in MSRC first — and what to expect from Microsoft’s VEX/CSAF rollout​

Microsoft began publishing machine‑readable CSAF files in late 2024 and added VEX attestations in October 2025, starting with the Azure Linux Distribution. That rollout explains why MSRC’s short product mapping frequently identifies Azure Linux as the Microsoft product that “includes this open‑source library and is therefore — Azure Linux was the first product family Microsoft targeted for per‑CVE attestation under the VEX program. Microsoft has publicly committed to updating CVE/VEX records when additional Microsoft products are found to ship the same upstream component.
Practical implication: expect MSRC to expand per‑product attestations over time. For now, use the Azure Linux attestation as an authoritative signal for those images; for other Microsoft artifacts, perform per‑artifact verification (see verification steps above) until MSRC publishes explicit attestations for them.

---

Recommended checklist for administrators and security teams​

• Inventory:
• 1.) Gather kernel artifacts and SBOMs for every Microsoft‑supplied image you run (Azure Marketplace images, AKS node images, Azure Linux nodes).
• 2.) Cross‑reference those artifacts against MSRC CSAF/VEX and distribution advisories to identify packages and kernel versions that include cdns3.
• Verify:
• 3.) On running systems, check for cdns3 presence (lsmod/modinfo) and kernel config (grep CONFIG_USB_CDNS3). If your images are read‑only or sealed, inspect the image build metadata or SBOM.
• Remediate:
• 4.) Apply vendor‑supplied kernel updates for affected branches as soon as they are available.
• 5.) If you cannot patch quickly, remove/blacklist cdns3 or avoid enabling NCM gadget functionality and review PREEMPT_RT usage.
• Monitor:
• 6.) Subscribe to MSRC and your distribution vendor advisories, and pull Microsoft’s CSAF/VEX attestations for automatic mapping into your vulnerability management pipeline.

---

Critical analysis — strengths and remaining risks​

Strengths

• Microsoft’s approach to publish machine‑readable CSAF and VEX attestations (star) is a positive step for supply‑chain transparency. It gives customers a precise, automatable starting point for triage and reduces noisy false positives. The blog and early VEX releases show the company is building an operational model to expand coverage.
• Upstream Linux and major distributions moved quickly to patch the cdns3 gadget code once the deadlock was identified; the patch strategy (disabling softirq during a threaded IRQ handler) is narrow and easy to reason about from a maintenance perspective. The fixes have been merged and backported in multiple stable branches, allowing vendors to issue targeted kernel updates.

Risks and open questions

• The attestation model depends on phased inventory work. Until Microsoft publishes VEX attestations for every product family that might ship Linux kernel artifacts, customers cannot rely on a single MSRC page to assert universal coverage. Absence of attestation should not be treated as proof of absence. This is an operational gap during the VEX rollout.
• Kernel variability makes automated mapping nontrivial: even within the same product family there can be multiple kernel builds with different CONFIG flags. Automated vulnerability tools that operate only on package names (without SBOMs or per‑artifact kernel configs) can miss exposures. Investing in per‑artifact SBOMs, kernel config capture, and VEX ingestion is necessary to get accurate coverage.
• Edge and embedded devices remain a higher‑risk domain. Devices that expose USB gadget functionality or ship PREEMPT_RT kernels are operationally more likely to be affected; organizations that manage device fleets should prioritize those artifacts for immediate review.

---

Final takeaways​

• Microsoft’s MSRC statement that Azure Linux includes this open‑source library and is therefore potentially affected is accurate and actionable for Azure Linux customers. It is not, however, a categorical or exclusive claim that no other Microsoft product contains the vulnerable cdns3 gadget code. (msrc.microsoft.com)
• Any Microsoft artifact that ships a Linux kernel built with CONFIG_USB_CDNS3 and gadget support enabled — or that inserts the cdns3 module into an image — could carry the vulnerability until patched. Confirm exposure by checking module presence and kernel configuration, and by reconciling SBOMs with vendor advisories.
• Remediate by applying vendor/kernel updates, or, as a short‑term workaround, avoid using the NCM gadget role and DO NOT run PREEMPT_RT‑enabled kernels in configurations that depend on cdns3 gadget functionality until fixes are deployed and validated.
• Use Microsoft’s CSAF/VEX attestations as they are published to automate mapping for Azure Linux and — as the VEX coverage expands — for additional Microsoft products. In the meantime, perform per‑artifact verification for other Microsoft‑supplied images rather than assuming they are unaffected.

If you manage cloud images, embedded device fleets, or Microsoft‑derived kernels, prioritize the verification steps and patch windows described above. Treat the Azure Linux attestation as a clear signal to act for Azure Linux images, and use the verification checklist to answer the same question for other Microsoft artifacts in your environment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center