CVE-2025-37780 Isofs Bug: Azure Linux Attestation Explained

Microsoft’s public mapping for CVE‑2025‑37780 names the Azure Linux distribution as a confirmed carrier of the vulnerable code, but that attestation is a product‑scoped inventory statement — not a mathematical guarantee that no other Microsoft product or image can contain the same vulnerable Linux kernel code.

Background / Overview​

CVE‑2025‑37780 is a Linux kernel vulnerability discovered by automated kernel testing (syzbot) and fixed upstream in the Linux stable trees in mid‑2025. The defect is a slab out‑of‑bounds read in the ISO‑9660 (isofs) filesystem code: the function responsible for turning a file handle into its parent reference, isofs_fh_to_parent, can be given a handle that is too small (12 bytes) while the code proceeds to read fields that require at least 16 bytes. The result is a read past the allocated buffer which KASAN (Kernel Address Sanitizer) flagged in the reproducer trace.
In plain terms: the isofs layer tried to interpret an undersized externally supplied file handle as if it contained more data than it did. That mismatch can cause the kernel to read memory outside the intended buffer, producing instability and, in some configurations, denial‑of‑service (kernel crash) conditions. The weakness was rated in the medium‑to‑high range by several vendors; CVSS vector summaries and vendor advisories place the score in the mid single digits (vendors vary the exact number), and multiple mainstream Linux distributions issued patches within weeks of the upstream fix.

---

What Microsoft actually said — and what that wording means​

Microsoft’s machine‑readable VEX/CSAF entry for CVE‑2025‑37780 explicitly lists Azure Linux as a product that “includes this open‑source library and is therefore potentially affected.” The VEX artifact maps this vulnerability to specific Azure Linux kernel component builds (for example, the azl3 kernel entries referenced in the VEX JSON). Microsoft also documents the vendor remediation for its Azure Linux artifacts and indicates it will update the CVE mapping if additional Microsoft products are identified as shipping the affected upstream component.
That language — authoritative for Azure Linux — is what defenders should treat as Microsoft’s formal inventory statement. However, it is crucial to understand two separate factual layers:

• Inventory attestation (what Microsoft has publicly audited and mapped): Microsoft has attested Azure Linux as including the vulnerable isofs code for CVE‑2025‑37780 at the time of publication.
• Binary/artifact inclusion (what may actually be present inside other Microsoft products): Many Microsoft products and services either ship Linux kernel binaries or host customer workloads that run Linux kernels (for example, WSL2 kernels embedded within Windows, Azure Marketplace images, or specialized kernels inside cloud appliances). Those artifacts can include upstream in which kernel version and config was used. Microsoft’s VEX attestation for Azure Linux does not itself prove absence of the vulnerable code from other Microsoft kernels or images — only that Azure Linux has been inventoried and is known to be affected.

Put bluntly: Microsoft has publicly attested Azure Linux; it has not publicly attested other Microsoft products as affected — but the absence of an attestation is not a proof of absence.

---

Technical deep dive: what the bug is, where it lives, and why it matters​

The vulnerable code path​

• Component: Linux kernel, fs/isofs (ISO‑9660/rock‑ridge) export/filehandle handling.
• Function of interest: isofs_fh_to_parent (and the broader handle_to_path / handle_open code paths that depend on it).
• Fault mode: slab out‑of‑bounds read when a supplied file handle length (handle_bytes) is smaller than the code assumes. The reproducer used a handle_bytes value of 12; downstream code reads parentblock which requires at least 16 bytes, producing a read past the end of the allocated f_handle buffer. This was captured in a KASAN trace.

Why an out‑of‑bounds read matters: read‑only out‑of‑bounds accesses can still destabilize the kernel (KASAN triggers, oops, panic) and, on some architectures or configurations, may be exploitable in more complex chains. At minimum, the bug provides a reliable way to crash a kernel context that processes malformed file handles — a service disruption risk on systems that expose handle‑based APIs or mount isofs images under adversarial control. Several vendor advisories classify the resulting impact primarily as availability risk (DoS) rather than immediate remote code execution, but the kernel context means the impact surface is inherently sensitive.

Affected versions and distributions​

Upstream CVE records and aggregator services list a broad range of kernel versions as potentially vulnerable — the practical set depends on whether the shipped kernel contains the isofs code paths unchanged by upstream stable fixes. Multiple mainstream distributions (Ubuntu, Amazon Linux, SUSE, Debian, etc.) published vendor advisories and pushed kernel updates that incorporate the upstream fix. Microsoft’s Azure Linux advisory maps specific azl3 kernel builds to the fix and publishes vendor remediation notes for Azure Linux images.

---

Is Azure Linux the only Microsoft product that includes the isofs code?​

Short answer: No, not necessarily — but yes, officially Microsoft has only attested Azure Linux so far.

• Official attestation: Microsoft’s public VEX/CSAF mapping explicitly lists Azure Linux (specific azl kernel components) as the Microsoft product that “includes this open‑source library and is therefore potentially affected.” That is the formal, published statement from Microsoft’s security inventory work.
• Practical/technical reality: Microsoft produces and distributes Linux kernels in several contexts (Azure‑tuned kernels for VM images, kernels in Marketplace images, and the kernel used by WSL2 on Windows clients among others). If those other kernels are compiled from upstreain the isofs code without the upstream fix, they may also be vulnerable — but identifying them requires per‑artifact inventory (checking the kernel version/build and whether the vendor applied the specific isofs fix). Microsoft has promised to update CVE mappings if additional Microsoft products are found to ship the affected component; until such mapping appears, defenders must assume possible exposure and verify locally.

In practical terms: treat Azure Linux as a confirmed hit and act immediately on that, but do not assume WSL2, Azure Marketplace images, or other Microsoft Linux artifacts are safe just because they are not listed in the VEX. Those other artifacts may or may not be affected depending on which kernel version and patch set they include.

---

Evidence from multiple independent sources​

• Microsoft’s VEX/CSAF entry maps CVE‑2025‑37780 to specific Azure Linux kernel component builds and lists vendor remediation timelines for those artifacts. That is Microsoft’s official inventory/attestation for this CVE.
• OSV and other vulnerability databases detail the technical cause (isofs_fh_to_parent slab out‑of‑bounds read) and the syzbot/KASAN reproducer that found the issue. Those records confirm the reproducer details and the recommended upstream fix.
• Major distribution advisories (for example, Ubuntu and Amazon Linux) posted their own CVE pages and kernel update notes, showing the issue was accepted upstream and that multiple mainstream vendor kernels received updates. These vendor pages provide concrete kernel package identifiers and remedial package versions tied to the fix.
• Independent aggregators and CVE feeds list the version ranges and expanded set of affected kernels, providing a cross‑reference for defenders validating whether a given kernel build falls into the vulnerable range.

These independent sources converge on the same technical facts: an isofs filehandle length check was insufficient and the upstream hecks / guarded access paths to prevent out‑of‑bounds reads.

---

Risk analysis: who should care, and why​

• Azure Linux customers: Confirmed. Microsoft has attested Azure Linux and published (machine‑readable) remediation guidance for Azure Linux images and azl kernel packages. If you run Azure Linux images or manage VMs based on Microsoft‑provided azl kernels, apply the vendor updates promptly.
• Azure Marketplace images and customer‑supplied images: Mixed. Marketplace images may be built from many upstream kernels; some will have thd updating. Treat each image/artifact as a separate inventory item and check kernel versions.
• Windows Subsystem for Linux (WSL/WSL2) users: Worth verifying. WSL2 runs a Linux kernel maintained by Microsoft and shipped via Windows Update or WSL kernel packages. Whether a specific WSL installation is vulnerable depends on the kernel build shipped into the Windows release you run. Until Microsoft maps WSL explicitly in a VEX entry for this CVE, administrators should check kernel versions and apply the WSL kernel update mechanism or Windows Update when Microsoft publishes a fix. This is a product that deserves special attention because it runs on client desktops and can be exposed to local user‑supplied content.
• On‑premises Windows servers or appliances that embed a Linux kernel (for example, certain subsystem components or specialized offerings): Rare but possible. Any Microsoft product that bundles a Linux kernel requires artifact inspection.
• Cloud providers, distributions, and embedded systems: Many Linux stacks include isofs; distribution maintainers already published patches. If you run non‑Microsoft Linux images (Debian, Ubuntu, Red Hat, SUSE, Amazon Linux), follow the vendor advisories and apply kernel updates.

The underlying risk profile is therefore context‑sensitive: the bug is not a wide‑open remote code execution on all systems, but it is a kernel‑level memory safety defect that can trigger service disruption and which, in certain chains, may be used in more complex attacks. That means defenders should prioritize exposures where malformed ISO images or handle‑based APIs are reachable.

---

Practical detection and mitigation checklist​

Below is a practical, prioritized checklist for defenders who want to identify and mitigate exposure across environments.

1) Inventory: find where the vulnerable code could be present​

• On Linux systems, run uname -r and check the kernel package version against vendor advisories and the version ranges pu If your kernel matches versions listed as affected, assume the kernel needs update. (Example: check /proc/version and vendor kernel package metadata.)
• On Azure: identify VMs running Azure Linux images or azl kernels; Microsoft’s VEX mapping lists azl3 kernel components as known affected artifacts. Apply Azure Linux updates per Microsoft’s remediations.
• For WSL2: inside your WSL instance run uname -a to see the kernel build string. If you maintain large fleets, automate extraction of kernel strings and compare against fix lists. If WSL is shipping a vulnerable kernel build for your Windows release, expect Microsoft to publish a fix path via WSL kernel updates or Windows Update.

2) Apply vendor fixes​

• Prioritize Microsoft‑attested artifacts first (Azure Linux images and azl kernel packages). Microsoft’s VEX entry includes remediation notes and dates for Azure Linux builds — apply those vendor packages promptly.
• For other Linux distributions (Ubuntu, Amazon Linux, SUSE, etc.), apply the vendor kernel security updates listed in their advisories. Many distributions rolled patched kernel packages within days.

3) Temporary mitigations where immediate patching isn’t possible​

• If isofs is a loadable module on a particular host and the host does not need ISO‑9660 support, unload it and blacklist it as a stopgap:
• Unload: sudo modprobe -r isofs
• Prevent loading on reboot: echo "blacklist isofs" | sudo tee /etc/modprobe.d/disable-isofs.conf
• Caution: built‑in kernels (where isofs is compiled into the kernel rather than a module) cannot unload the driver; blacklisting only works for modules. Confirm by checking kernel config (for example grep -i isofs /boot/config-$(uname -r) — look for =m to indicate module). These measures prevent a local path to the vulnerable code but may break legitimate ISO mounts. Use as a temporary mitigation only.
• Restrict access to interfaces that accept file handles or to untrusted automatic ISO mounting workflows when unpatched kernels remain in service.

4) Monitoring and detection​

• Watch for KASAN oops or kernel tracebacks referencing fs/isofs/export.c or isofs_fh_to_parent in system logs. Those kernel oops lines match the KASAN call stacks included in the reproducible reports. If you see those signatures in logs, treat them as high‑priority indicators.

---

How to validate Microsoft’s attestation and keep tracking changes​

• Microsoft’s VEX/CSAF feed is designed to provide machine‑readable product mappings; consult the Microsoft VEX JSON forrify which Microsoft artifacts are explicitly mapped and whether Microsoft has updated the mapping after your initial check. Microsoft has said it will add additional products to the CVE mapping if later inventory finds them to ship the affected component.
• Independently cross‑reference vendor advisories from distributions you run (Ubuntu, Red Hat, Amazon Linux, SUSE) and aggregators (OSV, NVD, cvefeed). That lets you reconcile Microsoft’s attestation with broader ecosystem data about which kernel versions are affected and which patches exist.
• For Windows and WSL: monitor Windows Update and the WSL kernel update channel; if Microsoft updates the WSL kernel to incorporate the isofs fix they will publish guidance through their normal channels (and may append WSL to their VEX mapping if they explicitly inventory that artifact). Until then, perform the artifact checks described above for on‑host W Strengths and shortcomings of Microsoft’s current public response

Notable strengths​

• Microsoft is publishing machine‑readable VEX/CSAF attestations and mapping specific Azure Linux kernel component IDs to CVE‑2025‑37780. That provides customers with a definitive, actionable starting point for Azure Linux remediation. The VEX format improves autots.
• The company has made a public commitment to expand the mapping if additional Microsoft products are found to ship the affected upstream component. That transparency is useful for enterprise customers performing supply‑chain risk assessments.

Potential gaps and risks​

• The VEX attestation is product‑scoped and time‑boxed: it covers the artifacts Microsoft has inventory‑checked so far (Azure Linux first), but it does not prove absence of the vulnerable code from other Microsoft kernels/ images. Customers can misinterpret Microsoft’s phrasing as a global all‑clear for Microsoft artifacts; that would be a dangerous mistake.
• Microsoft ships Linux kernels in multiple contexts (WSL, Azure Marketplace, images used by managed services). Without explicit attestation of those other artifacts, organizations must either perform their own artifact checks or wait for Microsoft to extend the VEX mapping — which creates a time window of uncertainty for large, heterogeneous fleets.

Because of these limits, defenders should treat Microsoft’s attestation as authoritative for Azure Linux and as a prompt to inventory and validate other Microsoft‑supplied Linux artifacts in their environment.

---

Recommended actions for administrators and security teams​

• Treat Azure Linux as confirmed affected and apply the Microsoft Azure Linux security updates immediately. Automate remediation across Azure VM fleets using your normal image/patch management workflows.
• Inventory all systems that run Linux kerse — including WSL installations on developer and desktop endpoints, Azure Marketplace images, and any Microsoft‑packaged virtual appliance — and verify kernel build strings. Prioritize patching where kernels match affected version ranges reported by vendors.
• Where patching is delayed, and the isofs module is not required, consider temporary module unload/blacklist mitigations, combined with monitoring for relevant KASAN/oops signatures. Use those mitigations only as stopgaps.
• Subscribe to VEX/CSAF feeds and vendor advisory channels (Microsoft, upstream distros) and automate parsing of those feeds to drive patch orchestration. Microsoft’s machine‑readable VEX entries make automation straightforward for Azure artifacts; use aggregator feeds for the broader Linux ecosystem.
• For organizations with compliance obligations: document the discovery, inventory, and remediation steps. If Microsoft later extends its VEX to aeconcile that mapping against your inventory and re‑prioritize accordingly.

---

Final assessment and closing guidance​

CVE‑2025‑37780 is a real kernel memory‑safety defect in the isofs filesystem code that multiple vendors confirmed and patched. Microsoft’s public, machine‑readable inventory work currently lists Azure Linux as the Microsoft product known to include the implicated upstream component, and Microsoft has committed to update the CVE mapping if other Microsoft products are later found to ship the same code. That official attestation is authoritative for Azure Linux today — but it is not a universal guarantee that other Microsoft artifacts (WSL kernels, Marketplace images, etc.) are unaffected. Administrators must therefore perform their own artifact‑level verification for all Microsoft‑supplied or Microsoft‑maintained Linux kernels in their environments and apply vendor updates where necessary.
In short: treat Azure Linux as the confirmed Microsoft‑attested carrier and patch it immediately; treat all other Microsoft kernels as potentially exposed until verified; and use Microsoft’s VEX/CSAF feed plus vendor advisories to drive fast, automated remediation across your estate.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center