The public advisory for CVE-2024-35794 identifies a Linux-kernel race/teardown defect in the device-mapper RAID code (dm-raid) that can leave the RAID sync thread in an unexpected state during suspend, and Microsoft’s published response confirms that Azure Linux has been inventoried and mapped as “potentially affected” — but that attestation is product-scoped, not a categorical guarantee that no other Microsoft artifact can carry the same vulnerable code.
CVE-2024-35794 is an upstream Linux-kernel fix addressing the dm-raid (md) code that governs RAID array background synchronization and suspend/resume behavior. The flaw stems from incorrect handling of the MD_RECOVERY_FROZEN flag and the sequence of calling stop_sync_thread/md_stop_writes, which in some interleavings can leave the sync_thread running or allow it to restart unexpectedly while the array is suspended — producing hangs, data-corruption risks during a suspend/resume cycle, and availability loss. Upstream maintainers produced focused patches that adjust where the MD_RECOVERY_FROZEN flag is set and ensure the correct stop/drain semantics for the sync thread. Linux distributors (Ubuntu, SUSE, Red Hat and others) have cataloged the defect and published distribution-level advisories and package mappings; the vulnerability is classified in vendors’ trackers as primarily an availability/stability issue (local vector, non-privileged/low-privileged local access may be sufficient to trigger the condition in some contexts).
It is crucial to read that phrasing literally: Microsoft is declaring what it has validated so far (Azure Linux), and promising to expand the public attestations when additional inventory finds other Microsoft artifacts that ship the same library. It is not a technical statement that other Microsoft products cannot contain the library — only that Microsoft has not yet attested them in its public VEX/CSAF outputs.
However, that statement is intentionally scoped. The correct operational posture for defenders is to treat Microsoft’s attestation as a high-confidence confirmation for Azure Linux, while simultaneously performing artifact-level verification across other Microsoft-supplied kernels and images in their environment. Kernel inclusion is a build-time property; therefore, presence of vulnerable dm-raid code is possible anywhere Microsoft ships a Linux kernel — from WSL2 kernels to linux-azure builds to marketplace appliances — until an attest or explicit vendor advisory says otherwise.
Independent vulnerability trackers (NVD, distro advisories, OSV) corroborate the technical diagnosis and list the upstream commits that remedied the issue. Those sources should be used to map fixes to specific package versions and commits as part of an evidence-based remediation workflow.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE-2024-35794 is an upstream Linux-kernel fix addressing the dm-raid (md) code that governs RAID array background synchronization and suspend/resume behavior. The flaw stems from incorrect handling of the MD_RECOVERY_FROZEN flag and the sequence of calling stop_sync_thread/md_stop_writes, which in some interleavings can leave the sync_thread running or allow it to restart unexpectedly while the array is suspended — producing hangs, data-corruption risks during a suspend/resume cycle, and availability loss. Upstream maintainers produced focused patches that adjust where the MD_RECOVERY_FROZEN flag is set and ensure the correct stop/drain semantics for the sync thread. Linux distributors (Ubuntu, SUSE, Red Hat and others) have cataloged the defect and published distribution-level advisories and package mappings; the vulnerability is classified in vendors’ trackers as primarily an availability/stability issue (local vector, non-privileged/low-privileged local access may be sufficient to trigger the condition in some contexts). What Microsoft has said — precise reading
Microsoft’s public vulnerability entry for this CVE includes the line you quoted: that “Azure Linux includes this open-source library and is therefore potentially affected,” and it states Microsoft began publishing machine-readable CSAF/VEX attestations for Azure Linux beginning in October 2025 and will update the CVE/VEX records if additional Microsoft products are identified to include the same upstream component. That wording is a product-scope attestation: it reports the result of Microsoft’s inventory work for the Azure Linux family at the time of publication.It is crucial to read that phrasing literally: Microsoft is declaring what it has validated so far (Azure Linux), and promising to expand the public attestations when additional inventory finds other Microsoft artifacts that ship the same library. It is not a technical statement that other Microsoft products cannot contain the library — only that Microsoft has not yet attested them in its public VEX/CSAF outputs.
Short answer to the user’s question
- No — Azure Linux is not necessarily the only Microsoft product that can include the vulnerable open-source code.
- Yes — Azure Linux is the only Microsoft product Microsoft has publicly attested (via CSAF/VEX) as including the affected component at the time of their advisory. Microsoft has committed to update the mapping if they discover more carriers.
Why the nuance matters (technical and operational reasoning)
- Build-time variability: Kernel components are included or excluded based on kernel configuration flags (CONFIG), module packaging, and the particular kernel commit used when building an artifact. Two Microsoft kernels can be built from the same upstream tree but with different CONFIG choices and therefore different surface area.
- Static and embedded binaries: A vulnerable kernel driver or code path can be present not only in vendor kernel packages but also in statically compiled appliances, containers, or system images that include a kernel or modules. Updating the OS package manager may not fix a statically built artifact loaded from a separate image.
- Marketplace and third-party images: Microsoft distributes and hosts many third-party or partner images and appliances in marketplaces; those images are the responsibility of their publishers and may not be covered by Microsoft’s Azure Linux attestation.
- Phased VEX publication: Large vendors commonly publish VEX/CSAF attestations in phases, starting with a narrow set of product families where inventories are complete. Microsoft’s initial rollout targeted Azure Linux; expect attestations for other Microsoft artifacts to follow as inventories are completed.
What kinds of Microsoft artifacts could carry the same dm-raid code?
Any Microsoft artifact that ships or builds a Linux kernel or kernel modules could, in principle, include the same vulnerable code if the kernel build included the md/dm-raid components and used a pre-fix commit range. Notable examples to consider:- Azure Linux images and kernels — explicitly attested by Microsoft.
- linux-azure kernel builds used on some Azure VM families and Marketplace images — these are separate kernel artifacts and may have different configs.
- The Windows Subsystem for Linux (WSL2) kernel — Microsoft publishes WSL2 kernel sources and a binary; whether a given WSL kernel build includes the md/dm-raid code depends on the kernel config used for that WSL release.
- Marketplace VM images, partner appliances, and container base images available through Azure — publisher responsibility; not automatically covered by an Azure Linux attestation.
- Internal/test images, device images, or appliance software that embed a Linux kernel binary.
Verifying exposure — practical, artifact-level checklist
For security teams responsible for mixed Windows/Linux estates, adopt a repeatable verification playbook. The following steps let you determine whether an individual host, image, or artifact is in scope.- Identify the kernel artifact being used:
- On a running Linux host: run uname -r and collect the kernel package name and vendor metadata.
- For VM images or appliances: inspect image manifests and build metadata, or mount the image and check /boot/config-* and vmlinuz strings.
- Check kernel configuration for md/dm-raid options:
- zcat /proc/config.gz | grep -E 'CONFIG_MD|CONFIG_BLK_DEV_DM'
- grep -E 'CONFIG_MD' /boot/config-$(uname -r)
- lsmod | grep md || modinfo md
- Map kernel version and vendor package to upstream commits:
- Consult your distro vendor advisory (Ubuntu, Red Hat, SUSE) or the NVD / OSV database to find the upstream stable commits fixing CVE-2024-35794, then verify whether your kernel package includes those backports. Distribution advisories list fixed package versions.
- For WSL2 and custom kernels:
- Check the WSL kernel version deployed on Windows and the WSL2 kernel config published by Microsoft; if you use custom kernels, verify the config and applied patches directly.
- For containers and static binaries:
- If images contain a kernel (appliance VMs) or embedded kernel modules, treat those images as first-class artifacts: inspect image layers, run strings against kernel binaries, and search for md subsystem symbols.
- If inventory is unclear:
- Treat the artifact as potentially affected until proven otherwise; isolate high-value workloads and prioritize hosts where the md/dm-raid driver is present or where RAID arrays are used and suspend/resume cycles are common (laptops, certain hypervisor guests, live-migration paths).
Immediate mitigations while you patch
If you cannot apply an upstream/supplied kernel update immediately, apply compensating controls to limit exposure and blast radius:- Reduce attack surface:
- Disable unused RAID arrays where possible, or unmount and stop arrays when not required.
- Remove or blacklist the vulnerable module (rmmod/blacklist) on hosts where md/dm-raid is not needed.
- Container and host hardening:
- Restrict unprivileged access to device nodes that could exercise the RAID driver (for example, restrict access to /dev/md and /dev/dm-).
- Control suspend/resume behavior:
- Avoid suspend/resume on affected hosts where practical, and prefer controlled shutdown/reboot cycles until patched.
- Monitoring and logging:
- Add kernel oops/stack trace monitoring, enable persistent kernel logging, and watch for symptoms (hung stop_sync_thread, repeated oops during resume, stalled IO). Set up automated alerts to capture relevant logs for forensic analysis.
Patching and the operational playbook
- Prioritize patch deployment for images Microsoft has attested as “known affected” (Azure Linux) — these are the highest-confidence, vendor-verified carriers and should be patched first. Microsoft’s CSAF/VEX outputs provide machine-readable metadata to automate triage and prioritization for Azure Linux images.
- For other Microsoft artifacts (WSL2, linux-azure kernels, Marketplace images), follow the verification checklist above. If a vendor-supplied kernel or image lacks a fix, coordinate with the image vendor (or Microsoft support for Microsoft-managed artifacts) for a backport or a patched artifact.
- Use configuration management (patch orchestration, kernel-package updates, image rebuilds) to push fixes systematically and to replace marketplace or custom images that embed vulnerable kernels.
Strengths and benefits of Microsoft’s CSAF/VEX approach
- Machine-readable attestations: Publishing CSAF/VEX for Azure Linux enables automation — security tooling can automatically correlate CVEs to named product artifacts and produce deterministic triage actions for affected Azure Linux instances. That materially reduces noisy triage and accelerates remediation for customers who run those Microsoft-published images.
- Clear, auditable vendor mapping: Microsoft’s product-scoped statements make it explicit which product families they have inventory-checked, which helps customers relying on those SKUs to prioritize remediation confidently.
- Commitment to expand coverage: Microsoft’s public promise to update CVE mappings when additional products are discovered to include the same component is operationally valuable — it turns a one-time attestation into an iterated inventory program.
Potential risks and gaps to watch
- Attestation scope vs. company-wide completeness: Attestations are only as comprehensive as the inventory work performed. Microsoft’s Azure Linux attestation is authoritative for that product family only; absence of attestations for other Microsoft products is not equivalent to proof of absence. Customers must not assume a single product attestation covers all Microsoft-supplied artifacts in their estate.
- Static and third-party images: Marketplace images, partner appliances, and statically linked binaries can embed older or unpatched kernel code. Those images often fall outside a vendor’s attestation coverage and must be verified separately.
- Time-lag risk: Large vendors publish attestations in phases. There can be a window between initial discovery and comprehensive mapping where other artifacts remain unscanned. Attackers and incident responders both watch this window.
- Operational complexity: Kernel backports and distribution packaging vary; a kernel binary may claim a patched semantic version while still lacking the upstream commit in question if packaging metadata is inconsistent. Always map to upstream commits when possible.
Recommended action plan for organizations (concise)
- Ingest Microsoft’s CSAF/VEX outputs for Azure Linux and automate triage for any Azure Linux images you run.
- Scan your inventory for kernel artifacts and image manifests: check WSL configurations, linux-azure kernels, marketplace images, and any appliance images in use.
- For any artifact that includes md/dm-raid code (or where you cannot rule-in absence), apply available kernel patches from your distro vendor or rebuild images with patched kernels.
- Apply compensating controls while patches are staged: disable suspend/resume on affected hosts, restrict device node access, and monitor kernel logs for signs of hangs or oops.
- Subscribe to vendor VEX/CSAF feeds and set automation to ingest updates — Microsoft will expand attestations if further Microsoft products are found to carry the vulnerable code.
Closing analysis — balance of assurances and caution
Microsoft’s statement that Azure Linux includes the open-source library and is “potentially affected” is accurate and valuable: it is an authoritative inventory signal customers can act on immediately for that product family.However, that statement is intentionally scoped. The correct operational posture for defenders is to treat Microsoft’s attestation as a high-confidence confirmation for Azure Linux, while simultaneously performing artifact-level verification across other Microsoft-supplied kernels and images in their environment. Kernel inclusion is a build-time property; therefore, presence of vulnerable dm-raid code is possible anywhere Microsoft ships a Linux kernel — from WSL2 kernels to linux-azure builds to marketplace appliances — until an attest or explicit vendor advisory says otherwise.
Independent vulnerability trackers (NVD, distro advisories, OSV) corroborate the technical diagnosis and list the upstream commits that remedied the issue. Those sources should be used to map fixes to specific package versions and commits as part of an evidence-based remediation workflow.
Final practical takeaway
Treat Microsoft’s Azure Linux attestation as an authoritative “yes” for that product family and prioritize patching those images immediately. For all other Microsoft artifacts in your estate, assume possible exposure and verify at the artifact level (kernel config, module presence, package changelog or upstream commit mapping). Use Microsoft’s VEX/CSAF feeds as automation inputs and watch for updates — Microsoft will expand the CVE mapping if further carriers are discovered — but do not substitute a single attestation for an exhaustive, host-level inventory and remediation process.Source: MSRC Security Update Guide - Microsoft Security Response Center
