CVE-2025-22022: Azure Linux Attestation and Per Artifact Verification

Microsoft’s short statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate for the Azure Linux product family—but it is a product‑scoped attestation, not a guarantee that no other Microsoft product ships the same vulnerable Linux kernel code; operators must treat Azure Linux as confirmed in‑scope while performing artifact‑level verification across other Microsoft kernels and images.

Background / Overview​

CVE‑2025‑22022 is a Linux kernel vulnerability fixed in upstream kernels in April 2025. The flaw is in the USB xHCI controller driver and concerns how NEC uPD720200 controllers handle isochronous endpoints and link TRBs during Missed Service Errors (MSEs). In some controller specimens the controller’s link‑chain behavior could lead to IOMMU faults and unexpected memory access patterns after an MSE, producing data corruption or cross‑endpoint contamination under certain workloads. The vulnerability has been documented by multiple downstream trackers and vendors. Two important, verifiable facts about this CVE:

• The technical fix is localized in the xHCI driver (transfer/link handling for isochronous rings) and was merged and backported in stable kernel trees.
• Vendor advisory pages and distribution trackers list the CVE and the affected packages; however severity scoring varies between trackers (see “Scoring and disagreement” below).

---

What Microsoft published — the literal reading​

Microsoft’s Security Response Center uses machine‑readable CSAF/VEX attestations to declare whether a Microsoft product includes an upstream open‑source component implicated in a CVE. In this case the public MSRC mapping (the short phrasing the user quoted) means Microsoft completed an inventory for the Azure Linux product family and found the implicated upstream kernel component present in those images; Microsoft therefore marked Azure Linux as “potentially affected” and committed to update the CVE/VEX mapping if additional Microsoft products are identified. This is Microsoft’s phased transparency model that began publishing VEX/CSAF for Azure Linux in October 2025. Key takeaway: Microsoft’s wording is an authoritative attestation for the named product family (Azure Linux). It is not an affirmative statement that all Microsoft products have been scanned and found clean.

---

The central question — Is Azure Linux the only Microsoft product that includes the affected open‑source library?​

Short answer: No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable kernel code. It is the only Microsoft product Microsoft has publicly attested (via CSAF/VEX) as including the component at the time of the advisory. Absence of attestation ≠ proof of absence.
Why that matters in practice:

• Microsoft ships multiple distinct kernel artifacts and Linux‑adjacent images that could, depending on kernel version and build configuration, include the same xHCI driver code:
• WSL2 kernel binaries and the microsoft/WSL2‑Linux‑Kernel source tree;
• CBL‑Mariner and other Microsoft‑maintained distro artifacts (linux‑azure builds, host images);
• Marketplace VM images and third‑party appliances Microsoft distributes; and
• Appliance containers, managed node images (AKS node images), and other curated images.
• Each artifact is a separately built binary: whether the vulnerable file or code path is present depends on the kernel version, the exact upstream commit, and kernel CONFIG options used at build time. A single VEX attestation for Azure Linux cannot prove the same code does not appear in other artifacts.

---

Evidence and independent verification​

Multiple independent sources document the CVE, describe the vulnerability, and show vendor mappings. When evaluating Microsoft’s attestation, the sensible cross‑check is to consult upstream and distribution trackers:

• The NVD (National Vulnerability Database) entry for CVE‑2025‑22022 documents the issue and the upstream description of the fix.
• Major distro trackers and vendor advisories (Oracle Linux, SUSE, Amazon ALAS) list the CVE and the affected kernel packages; these pages confirm the technical synopsis and the timeline for fixes.
• Open Source Vulnerability (OSV) and other vulnerability aggregators also aggregate the CVE details and vendor mappings, and in some cases show variant CVSS scoring.

Taken together, these independent sources corroborate:

• the vulnerability exists and was fixed in upstream trees; and
• many downstream distributors and cloud vendors have published advisories and mapped fixes.

---

Scoring and disagreement — why CVSS numbers can vary​

Different trackers list different CVSS base scores for CVE‑2025‑22022:

• Amazon’s ALAS listing indicates a CVSS v3 base score of 5.5 (medium), reflecting a local/low-remote-exposure view.
• Some OSV/debian imports and aggregator listings report different severity (for example, entries that list a higher score), because vendors may assess impact scope and confidentiality/integrity differently for their environments.

Practical consequence: treat vendor CVSS numbers as guides for prioritization, not absolute truth. For hybrid estates, prioritize patching by exposure: hosts that accept untrusted USB attachments, hypervisor hosts exposing physical USB controllers to guests, or multi‑tenant infrastructure should be prioritized higher.

---

Technical summary (what the bug does)​

• Component: Linux kernel USB xHCI stack (transfer/link handling on isochronous rings).
• Trigger: Missed Service Errors (MSE) on NEC uPD720200 controllers that can cause misinterpreted Link TRBs or erroneous jump behavior across transfer ring segments.
• Risk: IOMMU faults and potential data corruption or cross‑endpoint writes in particular configurations; primary real‑world impact is data integrity and availability, not confirmed remote code execution in published records.
• Fix: Upstream change applies link‑chain quirk handling for NEC isoc endpoints; stable branch backports were published and vendor packages were updated.

---

Practical verification: how to determine whether your Microsoft‑supplied artifact is affected​

Artifact verification must be per artifact. Do not assume that an Azure Linux VEX attestation covers WSL2 kernels, Marketplace images, or other Microsoft artifacts.
Follow these prioritized steps:

• Inventory: Identify every Microsoft‑supplied Linux artifact in your estate:
• Azure VM images (note whether they are Azure Linux or vendor distro images).
• WSL2 instances and whether they use the Microsoft WSL2 kernel or a custom kernel.
• Marketplace VM images, AKS node images, and any Microsoft curated images.
• Identify running kernel/version:
• Run: uname -a
• Check package provenance: for RPM systems: rpm -q kernel-$(uname -r) ; for Debian/Ubuntu: dpkg -l | grep linux-image
• Inspect kernel config: zcat /proc/config.gz | grep -i xhci
• Confirm presence of the xHCI driver code:
• If xHCI is a module: lsmod | grep xhci ; find /lib/modules/$(uname -r) -type f -name 'xhci*'
• If built-in: grep -i xhci /boot/config-$(uname -r)
• Search for the referenced file path or module name corresponding to drivers/usb/host/xhci‑ring.c
• Map your kernel package to upstream commits or vendor advisories:
• Consult the vendor package changelog for the kernel package to find the upstream commit IDs referenced in linux‑cve‑announce or the distro advisory. If the package changelog references the upstream commit used to fix CVE‑2025‑22022, treat the package as patched.
• If you cannot confirm a quick fix, apply compensating controls:
• Restrict hot‑plug USB capability on sensitive hosts.
• Disable USB passthrough to untrusted guests in virtualization platforms.
• Isolate hosts that accept USB devices from untrusted parties until patched.
• Test in staging:
• Deploy patched kernel to staging hosts and exercise isochronous USB devices (audio/video) that generate sustained transfer loads and MSE-like conditions; monitor for xHCI warnings in kernel logs.

---

Remediation and operational playbook​

• Immediate priority: Azure Linux images flagged by Microsoft’s CSAF/VEX — update Azure Linux images per Microsoft guidance and apply the vendor-supplied kernel updates. Treat these as high-priority because Microsoft attested they include the component.
• Next: Inventory other Microsoft artifacts (WSL2, CBL‑Mariner artifacts, linux‑azure kernels, Marketplace images) and validate per the checks above. Patch or rebuild images as needed.
• For managed nodes (AKS, VMSS): plan node replacements/rolling reboots after node images are patched.
• For endpoints where immediate patching is not possible: reduce exposure by disabling USB ports or limiting kernel module load capability via module blacklisting where feasible.
• Monitor kernel logs for xHCI/xrun/MSE traces and create SIEM rules to aggregate and alert on those messages.

---

Detection and monitoring guidance​

• Tail kernel logs with filters for xhci/xrun/Miss Service Interval errors: dmesg, journalctl -k. Look for traces referencing TRB/TD DMA addresses and AMD‑Vi IOMMU events.
• Device symptoms to watch: repeated isochronous stream failures (audio/video stuttering), unexpected disconnects under load, or repeated IOMMU page‑fault events tied to USB host controllers.
• Virtualization: watch guest stalls during USB passthrough activities; monitor hypervisor logs for guest USB failures.

---

Strengths and weaknesses in Microsoft’s approach​

Strengths

• Machine‑readable VEX/CSAF: Publishing VEX attestations for Azure Linux gives customers a deterministic, automatable signal to triage and prioritize remediation. Microsoft’s October 2025 launch of VEX/CSAF for Azure Linux is material progress for supply‑chain clarity.
• Explicit naming: Calling out Azure Linux gives customers a concrete start point for remediation.

Weaknesses and residual risks

• Phased attestation = coverage gaps: Microsoft’s initial VEX rollout focused on Azure Linux; the phased approach means other Microsoft artifacts may still await inventory and attestation. That leaves potential blind spots for WSL2, Marketplace images, and internal builds.
• Customer assumptions: Organizations that assume “if it’s not listed, it’s safe” risk false reassurance. Artifact‑level verification remains the only defensible approach.
• Scoring inconsistency: CVSS and severity assignments differ between vendors—this can create inconsistent prioritization signals in mixed environments. Rely on exposure and role (hypervisor, multi‑tenant host, devices accepting USB from untrusted sources) when prioritizing.

---

Common operational pitfalls and how to avoid them​

• Pitfall: Relying solely on the MSRC attestation scope — many teams stop after reviewing the Microsoft page and assume only Azure Linux is affected.
• Avoidance: Automate artifact scanning and SBOM/SCA reconciliation for all Microsoft images in your estate.
• Pitfall: Assuming vendor CVSS is universal — different vendors may assign different base scores.
• Avoidance: Prioritize by exposure (e.g., hosts accept USB devices, are hypervisors, or run multi‑tenant workloads) rather than raw score alone.
• Pitfall: Not checking WSL2 developer endpoints — many organizations overlook developer machines as a risk vector.
• Avoidance: For WSL2, check uname -r inside the distro and compare the version to the upstream fixed versions; update WSL2 kernel packages or require Windows Update patches where MSRC indicates updates are available.

---

How to prove (definitively) whether a Microsoft artifact is affected​

The only definitive proof is artifact‑level evidence:

• The vendor kernel package changelog identifies the upstream commit hash used to fix CVE‑2025‑22022 (map the commit to the linux‑cve‑announce stable commit). If the package lists the commit, the package is patched.
• Or: unbundle the image and inspect the kernel and modules for the presence of the affected driver (drivers/usb/host/xhci‑ring.c path/symbols) and confirm build time configuration flags.

If you maintain custom kernels (WSL custom kernel or image rebuilds), compare your source tree and applied patches against the upstream commit IDs used to fix the CVE.

---

Final assessment — concise operational guidance​

• Treat Microsoft’s Azure Linux VEX attestation as authoritative for Azure Linux and remediate those images immediately according to Microsoft guidance.
• Do not assume other Microsoft products are unaffected simply because they are not yet attested. Inventory and verify every Microsoft kernel artifact you run (WSL2, CBL‑Mariner, linux‑azure, Marketplace images, managed node images).
• Map kernel package changelogs to upstream commit IDs in linux‑cve‑announce or vendor advisories—this is the most defensible evidence a kernel package is patched.
• Where immediate patching isn’t possible, apply compensating controls: restrict USB hot‑plug access, remove USB passthrough to untrusted guests, and monitor kernel logs for xHCI/IOMMU errors.

---

Closing analysis — strengths, risks, and how to remain defensible​

Microsoft’s CSAF/VEX attestation for Azure Linux is an important step: it gives Azure customers a clear machine‑readable entry point to action. At the same time, the phased nature of Microsoft’s VEX rollout and the reality that many Microsoft artifacts are separately built and packaged mean that Azure Linux being attested does not imply exclusivity. Organizations must couple vendor attestations with artifact‑level verification and targeted mitigations.
The pragmatic posture is clear:

• Act fast on Azure Linux as attested.
• Inventory and verify other Microsoft images you run.
• Use vendor changelogs and upstream commit IDs as the authoritative proof of a patch.
• Prioritize remediation by exposure: hosts that accept untrusted USB devices or serve as hypervisors should be first in line.

Finally, because vendor attestations and vulnerability scoring can change as inventories complete and as vendors update CVE records, continue to monitor MSRC and vendor advisories for updated CSAF/VEX mappings and package changelogs and re‑run your artifact scans whenever new attestations are published.

---

Important note: some claims—specifically whether a given, unnamed Microsoft artifact (for example a particular Marketplace image or a specific WSL2 release) contains the vulnerable code—cannot be verified from high‑level attestations alone. Those are artifact‑specific facts that require either Microsoft to expand VEX coverage or the operator to inspect the artifacts directly; treat any unverified assertion about another Microsoft product’s status as uncertain until proven by changelogs or artifact inspection.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center