The Linux kernel change tracked as CVE-2025-37810 fixes a bounds-check omission in the DWC3 USB gadget driver — the event count read from the DWC3_GEVNTCOUNT register was checked only for zero, not for exceeding the event buffer length, which could permit an out‑of‑bounds memcpy and a kernel crash.
The vulnerability labeled CVE-2025-37810 lives in the usb: dwc3: gadget code path of the upstream Linux kernel. The defect is straightforward: the driver reads an event count from the hardware register DWC3_GEVNTCOUNT and copies that number of bytes from an event buffer without validating that the count is within the buffer’s allocated length. When the count exceeds the buffer length, a memcpy can read or write beyond the intended memory region, causing a kernel panic or other memory-corruption effects. Multiple downstream distributions and vendors have issued patches or advisories after the upstream kernel fix was committed.
Microsoft’s public guidance for this CVE (and a number of similar Linux-kernel CVEs) follows a concise, product‑scoped pattern: the Security Response Center (MSRC) has published advisories and machine-readable VEX/CSAF attestations that explicitly name Azure Linux as a product family that “includes this open‑source library and is therefore potentially affected.” Microsoft has also stated that it began publishing CSAF/VEX attestations in October 2025 and that it will update CVE/VEX pages if additional Microsoft products are discovered to ship the same upstream component.
This raises the practical question many customers and defenders ask first: when MSRC names Azure Linux, does that mean only Azure Linux is affected inside Microsoft’s product portfolio? The short, careful answer is: no — Azure Linux is the only Microsoft product the company has publicly attested (so far) to include the implicated upstream component for this CVE, but that attestation is product‑scoped and not a proof that no other Microsoft product could contain the same vulnerable code. Microsoft’s wording is deliberate and reflects a phased inventory-and-attestation process.
The company’s October 2025 MSRC blog post about VEX/CSAF explicitly describes a phased "crawl, walk, run" approach: starting with Azure Linux (formerly CBL-Mariner) and using VEX attestations to provide machine-readable "Known Affected / Not Affected / Under Investigation / Fixed" signals to customers and security vendors. Microsoft said this model reduces ambiguity and helps automate decisions across large fleets.
Critically, the presence or absence of a VEX attestation is an inventory signal, not a technical guarantee. Security teams should:
However, Azure Linux is the only Microsoft product Microsoft has publicly attested so far to include the vulnerable upstream code — that is a statement of inventory, not a categorical declaration of exclusivity. Other Microsoft artifacts may or may not include the same vulnerable code depending on kernel versions and build choices, and defenders should not infer safety from absence of an attestation. Treat MSRC’s attestation as authoritative for Azure Linux, perform artifact‑level verification for other Microsoft images you run, and prioritize patching and mitigations accordingly.
The security takeaway is simple but operationally important: use vendor VEX/CSAF data to accelerate triage, but supplement it with local verification and robust inventory practices so that “not yet attested” does not become “not yet fixed.”
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
The vulnerability labeled CVE-2025-37810 lives in the usb: dwc3: gadget code path of the upstream Linux kernel. The defect is straightforward: the driver reads an event count from the hardware register DWC3_GEVNTCOUNT and copies that number of bytes from an event buffer without validating that the count is within the buffer’s allocated length. When the count exceeds the buffer length, a memcpy can read or write beyond the intended memory region, causing a kernel panic or other memory-corruption effects. Multiple downstream distributions and vendors have issued patches or advisories after the upstream kernel fix was committed.Microsoft’s public guidance for this CVE (and a number of similar Linux-kernel CVEs) follows a concise, product‑scoped pattern: the Security Response Center (MSRC) has published advisories and machine-readable VEX/CSAF attestations that explicitly name Azure Linux as a product family that “includes this open‑source library and is therefore potentially affected.” Microsoft has also stated that it began publishing CSAF/VEX attestations in October 2025 and that it will update CVE/VEX pages if additional Microsoft products are discovered to ship the same upstream component.
This raises the practical question many customers and defenders ask first: when MSRC names Azure Linux, does that mean only Azure Linux is affected inside Microsoft’s product portfolio? The short, careful answer is: no — Azure Linux is the only Microsoft product the company has publicly attested (so far) to include the implicated upstream component for this CVE, but that attestation is product‑scoped and not a proof that no other Microsoft product could contain the same vulnerable code. Microsoft’s wording is deliberate and reflects a phased inventory-and-attestation process.
What the technical record shows
The root cause in plain terms
- The DWC3 gadget driver reads the hardware event count from the DWC3_GEVNTCOUNT register.
- The code verified if the count was zero but did not verify an upper bound relative to the allocated event buffer length.
- When a too-large event count is observed, the subsequent memcpy can overrun the buffer, causing an OOB access and likely a kernel crash (KASAN reports and crash traces were used by maintainers to identify the problem).
Scope and exploitability
- This is a kernel-level robustness bug with a local attack vector: an attacker with the ability to interact with the gadget interface or trigger device interrupts might induce the faulty code path. Vendors and distributors rate the issue as high‑severity in several advisories; upstream discussion and distributor errata show active patching across kernels used by major Linux distros.
Who shipped the fix, and where it appears
Downstream kernel packages (Ubuntu linux-azure kernels, enterprise distributions and vendor kernels) picked up the upstream fix in their stable kernel updates. Launchpad changelogs and distro advisories explicitly mention CVE-2025-37810 in linux-azure updates and other vendor advisories, confirming the bug existed in shipping kernel builds before the patch. That confirms Azure Linux — which uses Microsoft-maintained kernel builds for Azure VMs and images — contained the vulnerable upstream code prior to the update.Microsoft’s attestation model: what Microsoft actually said
Microsoft’s CVE pages for multiple Linux-kernel CVEs use the same FAQ text to answer the inventory question: they explain that Azure Linux includes the implicated open‑source library and is therefore potentially affected, emphasize Microsoft’s CSAF/VEX publishing that began in October 2025, and promise to update the CVE if further products are found to be impacted. That language is present across MSRC entries and is part of Microsoft’s broader transparency program.The company’s October 2025 MSRC blog post about VEX/CSAF explicitly describes a phased "crawl, walk, run" approach: starting with Azure Linux (formerly CBL-Mariner) and using VEX attestations to provide machine-readable "Known Affected / Not Affected / Under Investigation / Fixed" signals to customers and security vendors. Microsoft said this model reduces ambiguity and helps automate decisions across large fleets.
So — is Azure Linux the only Microsoft product affected?
- Microsoft’s public attestation: Azure Linux is the confirmed, attested carrier for the affected upstream component. That statement is authoritative for Azure Linux artifacts at the time of the advisory.
- But product-level attestation ≠ exhaustiveness: whether another Microsoft product (for example, a WSL2 kernel binary shipped inside Windows images, an Azure Marketplace appliance, a derived VM image, or some device firmware Microsoft tests and distributes) contains the same upstream source depends on build-time choices — kernel version, commit ranges, CONFIG_* settings, and what modules are compiled in. MSRC’s narrow wording reflects that operational reality: they attest what they have audited and will extend attestations as the inventory work continues. Absence of an attestation is not a guarantee of absence of the code — it is simply absence of public attestation.
- Practical implication: treat the MSRC attestation as an authoritative “yes” for Azure Linux and as an unverified state for other Microsoft artifacts until Microsoft publishes additional VEX/CSAF attestations or you perform your own artifact-level verification.
Why Microsoft uses the narrow attestation language (technical and operational reasons)
- Kernel diversity across artifacts: Microsoft ships multiple Linux kernel builds and images with different configuration options. The presence or absence of a specific driver in a product is an artifact-specific property. A vulnerability in upstream code therefore maps to a product only after the vendor verifies that the product’s binary actually includes the vulnerable source and that it was built from an affected commit range.
- Phased inventory approach: exhaustive per-artifact inventory across every product, image, VM SKU, and embedded firmware is time-consuming. Microsoft’s initial VEX rollout focuses on Azure Linux so they can perfect the tooling and processes before scaling to other product families. That operational constraint explains the “Azure Linux is potentially affected” phrasing versus a blanket enterprise-wide admission.
- Legal and supply-chain clarity: VEX/CSAF allows vendors to provide machine-readable, unambiguous attestations that reduce false positives for downstream defenders. The trade-off is time: machine‑readable attestations require disciplined per-artifact verification and may lag the initial disclosure for other product families.
How organizations should respond (practical guidance)
If you operate Microsoft-provided artifacts or consume Microsoft-built Linux images, follow this stepwise approach to make a defensible decision:- Confirm whether you run Azure Linux images or Microsoft-managed linux-azure kernels in your environment. If yes, treat this as a confirmed hit and prioritize patching. Apply the vendor-supplied kernel updates or the distribution kernel updates that include the upstream fix immediately.
- Inventory Microsoft artifacts you run that could embed a Linux kernel build: WSL2 distributions, Azure Marketplace images, Azure Kubernetes Service node images, managed VM images, Marketplace appliances, and device firmware provided by Microsoft partners. Identify the kernel version and build metadata for each artifact.
- For non‑Azure-Linux Microsoft artifacts: check whether the kernel binary or image includes the DWC3 gadget driver and whether the build’s upstream commit range pre-dates the upstream fix. If you cannot determine this via vendor-supplied metadata, extract the kernel image and use symbol tables or strings to verify presence of the driver. Where vendor transparency is missing, assume an unverified state and consider mitigation steps.
- Apply mitigation layers: if you cannot immediately patch, reduce exposure by disabling gadget functions where possible, restrict local access, and limit who can mount or interact with USB gadget endpoints on affected hosts. Where gadget functionality is required, prefer patched images or vendor-supplied updated kernels.
- Rely on VEX/CSAF but verify: ingest MSRC’s VEX/CSAF feeds (Microsoft publishes machine-readable attestations) to automate artifact status checks, but treat attestations as they are — the inventory for named products is authoritative; everything else remains unverified until attested or locally validated.
Risk assessment: attack surface, impact, and priorities
- Attack surface: the DWC3 gadget driver primarily affects systems that implement USB peripheral (gadget) functionality — commonly ARM-based SoCs and embedded platforms, but also VM images and cloud kernels that include gadget support. The attack vector is local. That reduces the immediate blast radius for purely cloud‑hosted, multi‑tenant services with network‑only exposure, but not for IaaS instances where local access or misconfigured privilege boundaries exist.
- Potential impact: kernel crashes (denial of service) are the straightforward outcome; depending on the exact memory overwrite or read, attackers could possibly escalate to memory corruption and more severe outcomes on some builds. Distributors have rated the issue high in CVSS terms and pushed patches across kernel trees.
- Operational priority: patch Azure Linux images now if you manage them. For other Microsoft artifacts, triage by inventory and exposure; where gadget drivers are unused in your workload, consider recompiling or deploying images without gadget support to reduce risk until you can verify vendor attestations or apply patches.
What Microsoft’s practice means for defenders and customers
Microsoft’s adoption of machine‑readable VEX/CSAF and the early focus on Azure Linux are positive developments: these standards reduce ambiguity and automate detection of affected product families. The trade-off is time and coverage: Microsoft publicly attested Azure Linux first and will expand attestations as inventory work proceeds. Until those attestations arrive, defenders must treat non-attested Microsoft artifacts as unverified, not safe. That distinction is crucial in supply-chain and incident-response contexts.Critically, the presence or absence of a VEX attestation is an inventory signal, not a technical guarantee. Security teams should:
- Ingest vendor VEX/CSAF feeds to automate triage.
- Maintain the capability to verify artifacts locally (extract kernel builds, check symbol tables, or compare build metadata).
- Coordinate with vendor support when vendor attestations are absent but risk is suspected.
Strengths, limitations, and policy implications
Strengths
- Microsoft’s VEX/CSAF move increases transparency and machine-actionable clarity for customers, reducing noise and enabling automated patch prioritization across large fleets. Starting with Azure Linux is pragmatic because it concentrates resources to refine the process before scaling.
- The upstream Linux community and distributors reacted quickly with patches and advisories, and major kernel trees were updated — enabling customers to obtain patched images or kernel packages promptly. Multiple distro advisories and launchpad changelogs show timely propagation of the fix.
Limitations and risks
- The attestation’s narrow wording can be misread by customers as meaning exclusivity; some organizations may interpret “Azure Linux is potentially affected” as “only Azure Linux is at risk.” That misinterpretation leaves other artifacts unverified and unpatched. Analysts and operators must resist that temptation and perform artifact‑level verification where critical systems are in scope.
- A phased VEX rollout inevitably produces timing gaps. The interval between upstream disclosure and full per‑artifact VEX mapping across all vendor products creates windows where defenders must choose between assuming the worst or investing in local artifact checks. That operational friction is real and should inform risk acceptance decisions.
Recommended checklist for administrators (quick actions)
- If you run Azure Linux images: apply kernel updates that include the CVE-2025-37810 fix immediately. Priority: high.
- If you run other Microsoft-provided Linux artifacts: enumerate kernels and images; confirm presence or absence of the DWC3 gadget driver and the relevant upstream commit range. If in doubt, treat the artifact as unverified and escalate to vendor support.
- Short-term mitigations: disable USB gadget functionality where it is not required, lock down local access, and restrict who can load/unload kernel modules. Consider network isolation for workloads that cannot be patched immediately.
- Long-term: integrate MSRC’s CSAF/VEX feeds into your vulnerability automation and continue to require per-artifact verification for vendor attestations in critical systems.
Conclusion
CVE-2025-37810 is a kernel-level buffer-bounds flaw in the DWC3 gadget driver that can cause out‑of‑bounds memcpy and kernel crashes. Microsoft’s public advisory correctly identifies Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” and Microsoft’s October 2025 VEX/CSAF program makes that attestation machine-readable for automation.However, Azure Linux is the only Microsoft product Microsoft has publicly attested so far to include the vulnerable upstream code — that is a statement of inventory, not a categorical declaration of exclusivity. Other Microsoft artifacts may or may not include the same vulnerable code depending on kernel versions and build choices, and defenders should not infer safety from absence of an attestation. Treat MSRC’s attestation as authoritative for Azure Linux, perform artifact‑level verification for other Microsoft images you run, and prioritize patching and mitigations accordingly.
The security takeaway is simple but operationally important: use vendor VEX/CSAF data to accelerate triage, but supplement it with local verification and robust inventory practices so that “not yet attested” does not become “not yet fixed.”
Source: MSRC Security Update Guide - Microsoft Security Response Center
