CVE-2024-42317 Azure Linux Attestation: Are Other Microsoft Products Affected?

Short answer (direct)

• No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable upstream code. It is the only Microsoft product Microsoft has publicly attested (via its advisory/VEX/CSAF process) to include the implicated open‑source kernel component for CVE‑2024‑42317 at the time of that advisory, but that attestation is product‑scoped and phased, not a proof that other Microsoft artifacts cannot contain the same upstream code. Independent trackers and the upstream kernel patch/commit show this is an upstream Linux kernel issue; Microsoft’s attestation covers Azure Linux first and Microsoft has said it will expand attestations if it finds the component in other products.

Why this question matters (brief)

• CVE‑2024‑42317 is a Linux kernel memory/page‑cache issue in mm/huge_memory that was fixed upstream. Whether any particular product is “affected” depends on whether that vendor’s shipped kernel binary (or other product artifact) actually contains the vulnerable codepath, and — for kernel vulnerabilities — whether the kernel was built/configured in a way that exposes the problem on the deployed architecture. You therefore must treat vendor attestations as product‑scoped inventory results rather than universal guarantees.

What CVE‑2024‑42317 is (technical summary)

• The vulnerability is in the Linux kernel’s huge_memory / page‑cache handling: xarray (the kernel’s data structure used for page cache metadata) does not support arbitrary huge page cache sizes. The maximum supported page cache size is bounded by MAX_PAGECACHE_ORDER; on some ARM64 systems with 64 KiB base pages it was possible for the huge‑memory collapsing path to create a 512 MiB page cache entry that exceeds the xarray limitations, which can trigger warnings and problematic behaviour when the xarray entry is split. The fix avoids creating PMD‑size (huge‑page) page cache entries that would exceed xarray’s supported limits. This is a kernel correctness/availability (denial‑of‑service or stability/diagnostic‑noise) class issue rather than a remote code‑execution vulnerability; the exact impact depends on architecture and runtime configuration.

Evidence and authoritative references

• NVD entry for CVE‑2024‑42317 — official public CVE metadata describing the problem and the affected kernel area.
• Upstream patch discussion / patch series that introduced the fix in mm/huge_memory (patch thread / patchew listing showing the changes and rationale). This is the primary (upstream) developer discussion and patch.
• Distribution tracking / advisories showing downstream packaging and fixes for Microsoft‑related kernels (example: linux‑azure packages used for Azure VM kernels and downstream advisories such as Ubuntu’s linux‑azure updates). These show that Azure‑specific kernels were updated to include fixes.
• Microsoft ships and maintains other Linux kernel artifacts — notably the WSL2 kernel source/binaries — in a public repository; this shows Microsoft has multiple Linux kernel artifacts beyond Azure Linux that could, depending on build/CONFIG choices and kernel version, contain the same upstream code. To determine exposure for a specific Microsoft product, you must examine that product’s actual kernel/artifact (or wait for Microsoft’s published VEX/CSAF attestation for that product).

Precision about Microsoft’s wording and what it means

• When Microsoft’s MSRC/Update Guide states “Azure Linux includes this open‑source library and is therefore potentially affected,” that is an authoritative product‑level attestation: Microsoft completed inventory for that product family and found the upstream component in the Azure Linux artifacts. Microsoft has also said it will publish machine‑readable attestations (CSAF/VEX) and update CVE mappings if/when it identifies the component in additional Microsoft products. That process and wording means Azure Linux is the only Microsoft product Microsoft has publicly mapped for this CVE so far, but it does not technically prove other Microsoft artifacts cannot include the same code. (User-provided MSRC advisory excerpt. For operational triage you should treat Microsoft’s Azure Linux attestation as canonical for Azure Linux images and simultaneously verify any other Microsoft images or kernel artifacts you actually run. (See “How to verify” below.

Why “only Azure Linux” is not the same as “no other Microsoft product is affected”

• Large vendors build many artifacts (cloud distro kernels, marketplace VM images, WSL kernels, appliance images, device images, installers, management agents). Each is built independently with its own kernel version and kernel config. An upstream kernel file can therefore be present in some artifacts and absent in others. Microsoft’s attestation model is phased: they publish attestations for a product only after inventorying that product; absence of an attestation for some other product means “not (yet) attested,” not “proven absent.” Practically, that means you should:
• Act immediately on Microsoft’s Azure Linux guidance if you run Azure Linux (it’s the canonical signal).
• At the same time, inventory and verify other Microsoft‑supplied artifacts you run (WSL kernels, Marketplace images, linux‑azure kernels, appliance images) rather than assuming they are clean.

How to check whether a given Microsoft artifact you run is affected (practical verification)

• The presence/impact is artifact‑specific; follow these verification steps for each artifact (Azure VM image, WSL install, Marketplace image, etc.:

1) Identify the kernel binary / kernel package and version

• On a running Linux image: uname -a (shows kernel version).
  Example:
• uname -a
• For packaged kernels (Ubuntu/CBL‑Mariner/etc.: inspect package names (apt/dpkg/rpm) or image manifest/SBOM.

2) Confirm kernel configuration and module presence

• List modules and check for relevant subsystems. Because CVE‑2024‑42317 is a mm/huge_memory (core VM) issue, the condition that made it observable upstream involved ARM64 + 64 KiB base page size and huge page collapsing. For kernel drivers you would check module presence like:
• lsmod | grep <module>
• ls /lib/modules/$(uname -r)/kernel/drivers/... (search for the specific files if the CVE were driver‑specific)
• For WSL: Microsoft publishes the WSL2 kernel source/configuration on GitHub; you can compare the WSL kernel config to upstream to see whether affected codepaths or options are enabled.

3) Check the runtime page size (to match the upstream reproduction condition)

• The upstream discussion shows the issue was triggered on ARM64 systems configured with 64 KiB base page size. On a running Linux instance you can check page size seen by the kernel process by inspecting smaps:
• cat /proc/1/smaps | grep KernelPageSize
• If KernelPageSize: 64 kB appears, that matches the ARM64/64 KiB condition described in the CVE notes. The upstream PoC and reproduction depend on that condition.

4) Search for the exact upstream commit/patch in your kernel

• Get the upstream patch reference (from the patch thread or distro changelog) and check whether the kernel tree shipped in the artifact includes the fix (e.g., grep the kernel source or the vmlinux for the changed symbol). If you run a distro package, check distro advisories/changelogs (Ubuntu linux‑azure, Red Hat, etc. for backports.

5) If in doubt, ask Microsoft for VEX/CSAF or SBOM evidence for the specific product

• Microsoft has committed to publishing CSAF/VEX attestations and expanding product mappings as they complete inventory. If you need an authoritative per‑product answer for something like WSL, Azure VM images or Marketplace appliances, request the product’s SBOM/VEX attestation from Microsoft support or consult the Microsoft Security Update Guide entry for the CVE you cited (the MSRC page). This is the formal route for vendor‑level confirmation.

What to do if you run Azure Linux (and why Microsoft singled it out)

• Microsoft’s public attestation says Azure Linux includes the open‑source library and is therefore potentially affected; Azure Linux kernel packages (linux‑azure) in downstream distributions were updated to include upstream fixes — update and reboot when your distro’s Azure kernel packages are available and marked fixed. For example, Ubuntu’s linux‑azure advisories list kernel updates that include many upstream fixes, and maintainers shipped linux‑azure package updates for Azure kernels. Patch/upgrade your kernel packages to the versions the distro or Microsoft/Ubuntu advisory recommends.

What to do if you run other Microsoft artifacts (WSL, Marketplace images, etc.

• Do not assume “not in the Microsoft attestation = safe.” Instead:
• Inventory the artifacts you run and check kernel versions, configs and module lists as described above.
• For WSL: Update Windows (WSL kernel updates are delivered via Windows Update or via the WSL2 kernel updates), and/or pull the latest Microsoft WSL2 kernel release or build a custom kernel with the fix. Microsoft maintains the WSL2 kernel source and publishes releases; keep your WSL kernel up to date.
• For Marketplace/VM images: check the image publisher’s advisory/SBOM; where the image uses an Azure‑branded kernel (linux‑azure) or a Microsoft‑curated kernel, watch for VEX/SBOM updates or package updates. If the image is vendor‑supplied by a third party, request the vendor’s SBOM or remediation timeline.

Mitigation options while you patch

• Short term:
• If your workload is not running on ARM64 with 64 KiB base page size (common on typical x86_64 VMs), this specific reproduction condition may not apply; still treat it as a kernel stability issue and follow normal patching hygiene. (Verify page size on hosts to be certain.
• Reduce exposure by limiting untrusted workloads’ ability to create the conditions that exercise huge_memory collapsing paths, and by applying standard kernel hardening/have good monitoring and alerting for kernel warnings or oops logs.
• Medium term:
• Apply the upstream kernel patch or the distro/vendor backport. Azure Linux (linux‑azure) package updates and other distro kernel updates incorporate upstream fixes; apply those updates and reboot.
• For WSL:
• Keep WSL updated via Windows Update or the WSL release channels; if you run a custom kernel, rebuild it with upstream fixes integrated.

Practical checklist for security/ops owners (one page)

• If you run Azure Linux images: follow Microsoft’s advisory for Azure Linux and apply the kernel updates Microsoft/distro published immediately.
• Inventory other Microsoft artifacts: WSL, Marketplace images, linux‑azure packages used in your environment, management agents, appliances. Don’t assume they’re unaffected.
• For each artifact, check:
• uname -a
• cat /proc/1/smaps | grep KernelPageSize
• lsmod and /lib/modules/$(uname -r)
• distro package changelog for kernel package (apt changelog / rpm -q --changelog)
• If you cannot verify quickly, request an SBOM / VEX attestation from Microsoft or your image vendor. Microsoft has committed to expanding VEX/CSAF attestations as they complete inventory. (MSRC advisory and VEX rollout comment; see Microsoft’s advisory text you provided.
• Patch and reboot kernel images as fixes are published. Monitor security advisories (NVD, distro advisories, vendor notices) for backports/fixes.

Concluding, actionable summary

• Microsoft’s advisory that “Azure Linux includes the open‑source library and is therefore potentially affected” is authoritative for Azure Linux images and should be acted on by Azure Linux users. However, that statement does not logically prove Azure Linux is the only Microsoft product that could include the affected upstream kernel code. Other Microsoft artifacts that ship kernel binaries (WSL2, Marketplace VM images, linux‑azure kernels used by distributions) may or may not include the vulnerable code depending on kernel version and build configuration — you must verify each artifact. The upstream patch and distro‑level advisories show the fix and the path to remediation; apply kernel updates (and for WSL, apply Microsoft/Windows updates that deliver the patched WSL kernel) and request SBOM/VEX attestations for any Microsoft product you need a definitive inventory for.

Key references (selected)

• NVD — CVE‑2024‑42317 (vulnerability description).
• Upstream patch / patch thread for mm/huge_memory “Avoid PMD‑size page cache if needed.” (patch discussion / Patchew record).
• Ubuntu / linux‑azure advisories and OSV listings (linux‑azure updates used for Azure VM kernels).
• Microsoft WSL2 Linux kernel source/repository (shows Microsoft ships a kernel for WSL and that kernel is public), for artifact verification of WSL builds.
• Debian security tracker / other vulnerability trackers corroborating CVE details.

If you want, I can:

• Check a specific Microsoft artifact you run (give me uname -a output, distro package names, or image IDs) and tell you whether it’s likely in‑scope and point to the exact package/build that contains the fix.
• Produce a short runbook (commands + email/template) you can use to request SBOM/VEX attestations from Microsoft or Marketplace image publishers.
  Which would you prefer next?

---

Source: MSRC Security Update Guide - Microsoft Security Response Center