CVE-2025-38146 Open vSwitch MPLS Dead Loop Causes CPU Soft Locks (Azure Linux Attested)

The Open vSwitch (OVS) MPLS parsing bug tracked as CVE-2025-38146 is a real kernel-level reliability vulnerability that can cause a CPU soft‑lockup by driving the MPLS parsing code into an infinite loop. Multiple independent trackers and downstream advisories confirm the technical root cause and the availability impact, and upstream kernel patches have been published to correct the parsing logic. Microsoft’s public statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is an authoritative, product‑scoped attestation: it confirms Azure Linux images are a known carrier and should be treated as in‑scope for remediation. However, that wording does not — and practically cannot — guarantee that no other Microsoft product or image includes the same vulnerable Open vSwitch code until Microsoft completes product‑by‑product inventory and publishes additional VEX/CSAF attestations.

---

Background / Overview​

Open vSwitch is a widely used virtual switch implementation that operates in the Linux kernel and in user space. It handles bridging, tunneling, and protocol parsing for virtualized networking stacks; in cloud and NFV environments it often processes complex encapsulations such as MPLS stacks. The recently assigned CVE‑2025‑38146 concerns an MPLS parsing routine in the kernel Open vSwitch code where unexpected MPLS inputs that do not terminate properly can cause the label‑count arithmetic to wrap and the parser to enter a dead loop, ultimately leading to soft lockups or a hung CPU core. The public vulnerability entries and vendor advisories describe the trigger as an array‑index out‑of‑bounds and a loop condition that fails to terminate in some malformed or malicious packet sequences.
Why this matters: a hung CPU on a packet‑processing core translates directly into lost packets, stalled virtualization I/O, and potentially full loss of network availability for tenants or VMs that rely on the affected datapath. In multi‑tenant cloud platforms and hosting appliances the operational pain can be severe: traffic stalls, instances unreachable, and operator intervention required to reboot or reload kernel state.
Multiple independent trackers observed the same details and timeline: the flaw was disclosed in early July 2025, upstream kernel commits were produced to address the parsing issue, and distribution vendors subsequently released patched kernel packages. The consensus view across trackers places this as a high‑importance availability bug rather than a straightforward remote code execution primitive, though as with many kernel defects, availability failures on hosted infrastructure can escalate operational risk significantly.

---

Technical analysis: what’s happening inside the kernel​

The bug, in plain English​

At the core, OVS’s MPLS parsing expects an MPLS label stack to terminate with the bottom label (where the bottom‑of‑stack bit is set). When an incoming MPLS packet lacks a proper bottom label or contains an intentionally crafted sequence of label headers, a loop that counts labels can wrap or index out of bounds. The parser code attempts to walk label entries using a counter or index that becomes invalid under those malformed conditions. In reported backtraces the kernel’s UBSAN instrumentation flagged an array index error in net/openvswitch/flow.c. The observable symptom is a soft lockup — a CPU stuck in kernel parsing loops — rather than a silent memory corruption exploit.

Why it matters operationally​

• The vulnerability is triggered by network traffic — not by local file or user inputs — so network‑accessible datapaths are the primary attack surface.
• The impact is availability-first: soft lockups, CPU stalls, and dropped processing on the OVS datapath.
• In cloud and virtualized environments, a single compromised tenant or a misrouted crafted packet stream could potentially affect forwarding on host nodes that execute the OVS datapath for many tenants.

Fix approach and upstream actions​

Kernel maintainers fixed the logic by adding appropriate bounds checks and loop‑termination guards to the MPLS parsing path. Those patches have been merged into the kernel stable trees for affected branches, and distribution maintainers have been mapping the upstream commits into vendor kernel packages and advisories. Patch rollouts were the standard corrective path: install a kernel package that contains the upstream commit or apply the specific upstream patch in your kernel builds. Multiple vulnerability databases and advisories documented the upstream commit references.

---

Microsoft’s statement and what it actually means​

The statement Microsoft published​

Microsoft’s Security Response Center (MSRC) published product‑level attestations as part of a phased rollout of machine‑readable VEX/CSAF files beginning with the Azure Linux Distribution. For CVE‑2025‑38146 Microsoft’s public product mapping includes the succinct sentence that “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability” and notes Microsoft will update CVE/VEX records if additional Microsoft products are identified as carriers. This language is consistent with MSRC’s published VEX strategy and their October 2025 rollout announcement.

How to read that sentence correctly​

• Authoritative for Azure Linux: When MSRC says a named product includes an upstream component, that is an authoritative attestation for that product. If you operate Microsoft‑published Azure Linux images, treat those images as confirmed carriers and prioritize patching them according to Microsoft’s guidance.
• Not a certificate of exclusivity: That same sentence does not — and should not — be interpreted as a guarantee that every other Microsoft product has been inspected and found clean. Microsoft’s VEX rollout is phased and product‑by‑product. Absence of an attestation for Product X is simply an absence of attestation, not evidence that Product X does not include the vulnerable code. Large vendors ship thousands of artifacts and must inventory them product‑by‑product.

Why vendors do product‑scoped attestations​

Product‑scoped attestations enable clear, automatable signals for specific images and packages. It is operationally impractical for a vendor to announce global non‑impact for all products without an exhaustive artifact inventory. Microsoft’s VEX approach reduces false negatives and gives customers machine‑readable, product‑level data — but it also means products are disclosed incrementally as inventory woroft.com]

---

The user’s question answered: is Azure Linux the only affected Microsoft product?​

Short answer: No — not necessarily, and not provably.

• Azure Linux is the only Microsoft product Microsoft has publicly attested so far to include the implicated Open vSwitch code for CVE‑2025‑38146. That attestation makes Azure Linux a confirmed carrier and puts it at the top of the operational priority list.
• However, Microsoft’s statement explicitly reserves the right to update the CVE/VEX entry if additional Microsoft products are later found to include the same upstream component. That phrasing reflects the practical reality that other Microsoft images and artifacts (for example, WSL kernels, Marketplace VM images, Azure Marketplace appliances, container base images, Azure Kubernetes node images, or vendor kernel packages Microsoft redistributes) might include the same upstream OVS code depending on how they are built and whether they ship the same kernel tree. Until Microsoft completes inventory and publishes product‑level VEX attestations for those artifacts, their status remains unverified rather than definitively not affected.

In short: treat Azure Linux as confirmed in‑scope and patch it. Treat other Microsoft products and images that include kernel components as potentially in‑scope until Microsoft publishes explicit attestations or until you verify component inclusion yourself via SBOMs, image scanon.

---

Operational guidance: what defenders and operators should do now​

This section gives a prioritized, pragmatic checklist you can apply immediately.

1. Immediate triage (minutes to hours)​

• Inventory any Microsoft‑published images you run that include a Linux kernel or Open vSwitch components: Azure Marketplace images, Azure Linux images, WSL kernel images, node images for AKS, and any Microsoft‑curated container / appliance images. Assume Azure Linux images are affected unless Microsoft’s VEX shows otherwise.
• On hosts where Open vSwitch is present, watch for CPU soft‑lockup symptoms (hung CPUs, kernel watchdog messages, repeated parser stack traces in dmesg).
• If you cannot patch instantly and your service is being actively impacted, consider temporarily disabling or unloading the openvswitch kernel module on systems where doing so is safe and will not break essential connectivity. This is a blunt mitigation and may not be feasible for production hypervisors that depend on OVS for critical switching.

2. Patch and update (days)​

• Apply vendor kernel updates that include the upstream fix. Verify that your distribution’s kernel package explicitly contains the upstream commit or the vendor’s advisory references the CVE fix. Major distributions and kernel trees were updated and tracked in the weeks following disclosure. Reboot into the patched kernel as required.
• For any custom or in‑house built kernels, merge or cherry‑pick the upstream patch from the stable kernel tree and rebuild. Test in a staging environment before wide rollout.

3. Artifact‑level verification (days to weeks)​

• Scan images and binaries with SBOM/image scanners that can detect the presence of Open vSwitch kernel objects or matching kernel build identifiers. Where you have Microsoft‑supplied images, compare their SBOMs or the Microsoft VEX/CSAF entries.
• For Microsoft artifacts that lack an MSRC attestation, request or check for VEX/CSAF entries. Microsoft has committed to incremental VEX publishing and will update CVE records if additional products are found to include the component.

4. Longer‑term hardening and detection (weeks to months)​

• Harden network ingress filtering for MPLS where feasible. If hosts do not need to accept raw MPLS from untrusted networks, place packet filters or ACLs at the edge to reduce exposure to malformed MPLS streams.
• Add monitoring for OVS health indicators, kernel soft‑lockup messages, and netdev/OVS stack traces in your logging pipelines.
• Integrate distribution vulnerability advisories and MSRC VEX/CSAF feeds into your patch automation and change windows, so product‑level attestations are consumed automatically and mapped to CI/CD and patch orchestration flows.

---

Detection guidance: what to watch for in the field​

Practical signs of an OVS MPLS parsing failure include:

• Kernel messages in dmesg showing repetitive stack traces tied to net/openvswitch/flow.c or UBSAN/out‑of‑bounds instrumentation.
• Hostwide CPU soft‑lockup messages or hung CPU watcher logs.
• Sudden and unexplained packet drops or one‑way traffic loss on interfaces serviced by OVS datapaths.
• Elevated CPU usage on one or a few cores handling packet parsing, with no corresponding userland process to blame.

For forensic triage, collect dmesg/journal outputs, kernel oops traces, and netstat/ifconfig/ovs‑vsctl state. Correlate the timing with any suspect external MPLS traffic sources or recent configuration changes around tunneling or OVS flow programming.

---

Risk assessment and exploitability​

• Attack vector: network‑facing packet parsing path (AV:N in some vendor mappings) but practically constrained by the need for MPLS packet reachability to the vulnerable parsing path.
• Privileges required: none in the classic local sense; the attacker needs network reachability to the OVS datapath and the ability to send specially crafted MPLS packet streams.
• Impact: availability (soft lockups leading to DoS or host instability). Some trackers record high CVSS values because of the severity of host-level availability consequences on shared infrastructure.

No significant exploitation campaigns were publicly reported at disclosure; however, the possibility of targeted attempts against exposed cloud control planes or NFV appliances means defenders should not defer patching.

---

Cross‑verifying the facts (sources and evidence)​

To make firm remediation decisions you should verify the following claims using at least two independent sources:

• The existence and technical nature of CVE‑2025‑38146 (Open vSwitch MPLS parsing dead loop) — confirmed by multiple vulnerability databases and advisories and by the kernel stable co
• That Microsoft has attested Azure Linux as a carrier via the VEX/CSAF rollout — confirmed in MSRC public communications about VEX and in Microsoft’s product‑levelat MSRC’s attestation as authoritative for Azure Linux.
• That other Microsoft products are not yet attested — evidenced by MSRC’s phased VEX approach and by the company’s explicit statement it will update CVE entries if additional products are identified. That absence of attestation is not a proof of absence and should be reflected in your risk calculations.

If you require absolute certainty about any Microsoft artifact, perform the artifact‑level verification (SBOM, image scan, or binary inspection) or wait for Microsoft’s product‑by‑product VEX attestations.

---

Practical checklist for Azure customers and defenders​

• Patch Azure Linux nodes immediately with kernels or packages that include the upstream fix. Confirm package changelogs include the CVE or the upstream commit.
• Inventory all Microsoft images you run that include kernels: AKS node images, Marketplace VM images, WSL kernel updates distributed through Windows Update, and any Microsoft‑curated appliance images. Treat these as unverified until VEX attestation or verification.
• If you manage multi‑tenant hosts where OVS is used to isolate tenant traffic, prioritize patching those hosts first. Considn of tenants that may send MPLS traffic from untrusted networks.
• Instrument and alert on kernel soft‑lockup messages and repetitive OVS stack traces. Capture forensics if you see a reproduction to help vendors analyze whether any further remediation is needed.

---

Notable strengths and potential risks in Microsoft’s approach​

Strengths​

• Product‑level VEX/CSAF attestations are clear and actionable. Microsoft’s VEX rollout gives a machine‑readable way to determine whether a named product includes a component — this reduces noise for defenders who would otherwise have to triage a huge set of vendor advisories manually. Microsoft’s transparency commitments improve automation and clarity.
• Phased rollout is pragmatic. Starting with Azure Linux lets Microsoft validate processes and partner interactions before scaling to hundreds or thousands of artifacts.

Risks / gaps​

• Phased attestation leaves many artifacts unverified for a while. Absence of a VEX entry for a product does not mean absence of the vulnerable component. Customers who run multiple Microsoft images must either rely on Microsoft to finish inventory or perform their own artifact scans.
• Operational burden shifts to customers in the interim. While Azure Linux customers get a clear signal to patch, operators using other Microsoft images must decide whether to assume risk, scan artifacts themselves, or wait for Microsoft’s attestations.

---

Conclusion​

CVE‑2025‑38146 is an important kernel‑level MPLS parsing bug that can cause CPU soft‑lockups through a dead loop in the Open vSwitch datapath. Upstream patches exist and vendors have issued updates; remediation is straightforward in principle (install the fixed kernel packages). Microsoft’s MSRC has properly attested that Azure Linux includes the implicated code and is therefore potentially affected — that attestation is authoritative for Azure Linux customers and should trigger immediate patching where applicable. However, Microsoft’s phrasing does not mean Azure Linux is the exclusive Microsoft carrier of the vulnerable code: the VEX/CSAF rollout is phased and product‑specific, and other Microsoft artifacts remain unverified until Microsoft publishes additional attestations or you confirm inclusion via SBOM/image scans.
Action items for defenders: patch Azure Linux now; inventory and scan all Microsoft images you run; instrument for OVS and kernel soft‑lockup indicators; and integrate MSRC VEX/CSAF feeds into your automation so product‑level attestations are consumed as they appear. That combined approach—patch first where attested, verify everywhere else—gives you the best balance of speed and assurance while Microsoft completes its phased attestations.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center