CVE-2025-38029 Linux KASAN Sleep in Atomic Context Fixed Azure Linux Patch

A recently assigned Linux-kernel vulnerability, CVE-2025-38029 — described as “kasan: avoid sleepable page allocation from atomic context” — has prompted an upstream kernel patch that removes a sleep-prone allocation in a KASAN-related path and has raised questions about which Microsoft products, if any beyond Azure Linux, might include the affected code and therefore require remediation.

Background / Overview​

The Linux Kernel Address Sanitizer (KASAN) is a dynamic memory-safety tool implemented in the kernel to detect out-of-bounds accesses and use-after-free conditions. KASAN is a compile-time/config-time option: it is present only in kernels built with CONFIG_KASAN enabled and in the specific KASAN variant selected (generic, software tagging, or hardware tagging). KASAN is widely used for kernel debugging and fuzzing and is often disabled in general-purpose production kernels because of its memory and performance cost. CVE-2025-38029 targets a KASAN code path (mm/kasan, specifically the populate-vmalloc path) in which apply_to_pte_range enters a lazy MMU mode and calls a callback (kasan_populate_vmalloc_pte for each PTE it walks. That callback can attempt to allocate a single page via a sleepable allocation; on some architectures (notably s390 in the reported case) the lazy-MMU enter/leave semantics can result in the kernel being in an atomic / non-sleepable context when the allocation happens, which provokes kernel assertions such as “sleeping function called from invalid context” and leads to oops/panic. The upstream fix is to ensure allocations performed by the KASAN populate routine are performed in a non-sleeping-safe way (or pre-allocated in bulk before walking PTEs) so the callback cannot sleep in an atomic context. This is a correctness fix addressing context discipline rather than a memory-corruption exploit primitive. The relevant upstream patch series and discussion were posted to the kernel mailing lists and stable trees (patch authorship and reviewers are visible on LKML / patchew threads), and stable-branch commits implementing the change were published so downstream distributors and vendors can backport the fix into their kernel packages.

---

Why this matters operationally​

• Primary impact: availability. The bug produces kernel BUGs or oops/panic conditions when the kernel attempts to sleep from an atomic context. Those symptoms cause immediate host instability and can force reboots or instance restarts; in shared or multi-tenant infrastructure this becomes an attractive DoS vector.
• Exploitability: low for remote compromise. There is no authoritative public proof that this specific issue produces a reliable arbitrary code-execution primitive; public trackers and vendor writeups characterize it as a correctness/availability issue. That said, kernel correctness bugs in privileged code paths are operationally significant and must be treated as high priority for infrastructure hosts.
• Scope depends on kernel configuration. Because KASAN is a kernel configuration option, only kernels built with KASAN enabled (or kernels that include the affected KASAN source compiled in) are actually susceptible. Most mainstream production kernels do not ship with KASAN enabled by default; KASAN is more common in debug, dogfood, or fuzzing builds.

---

What Microsoft has said (and what it means)​

Microsoft’s security guidance for CVE-2025-38029 indicates that the company’s Azure Linux distribution includes the open-source library at the heart of this CVE and that Azure Linux customers should expect Microsoft to keep that distro updated with the most recent, secure library versions. Microsoft also stated it is committed to transparency and will update the CVE if additional Microsoft products are found to be impacted. That statement effectively confirms Azure Linux as a known Microsoft product that bundles the affected component, while leaving open the possibility that other Microsoft products could be impacted after further inventory and analysis. Two practical implications from that statement:

• If you run Azure Linux images or Azure-managed services that rely on Azure Linux kernels, treat this as a confirmed vendor-mapped kernel issue and prioritize applying the Microsoft/azure-provided kernel updates once they are released.
• Microsoft’s phrase about updating the CVE implies they are actively scanning their product portfolio. If they find other products with bundled, KASAN-enabled kernels, they will revise the advisory and CVE product list accordingly. Until then, Microsoft’s public position is that Azure Linux is the Microsoft product confirmed to include the relevant open-source kernel code.

---

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

Short answer: Not necessarily — but as of Microsoft’s public advisory, Azure Linux is the only Microsoft product Microsoft has confirmed contains the affected code. Microsoft committed to updating the CVE if it identifies additional impacted products. That statement is explicit in their advisory text and is consistent with normal vendor vulnerability-mapping practice: vendors publish what they have verified and update the mapping as further internal inventories complete. To give this more context and independent verification:

• The underlying code lives in the Linux kernel source under mm/kasan; any Microsoft product that ships a Linux kernel built with KASAN enabled and that includes these files could theoretically be affected. Such products would include:
  • Linux distributions or images that Microsoft publishes (Azure Linux being the example Microsoft confirmed),
  • Instances where Microsoft supplies a Linux kernel binary (for example, the Microsoft-supplied kernel used by WSL2),
  • Vendor-supplied kernel binaries embedded in appliances, firmware, or specialized platform images that Microsoft might distribute.
• However, in practice Microsoft’s Windows-facing projects that touch KASAN are different beasts:
  • Microsoft has its own KASAN-related work for Windows kernel driver testing and MegaAsan/Microsoft kernel sanitizer initiatives, which are distinct implementations and uses of sanitizer technology for Windows drivers and the Windows kernel; that Windows-side KASAN work is not the same as the Linux mm/kasan code targeted by CVE-2025-38029. In other words, KASAN as a concept exists in both ecosystems but the Linux KASAN source in the kernel tree is a Linux-specific artifact and does not directly map to the Windows driver KASAN mechanism.
  • Microsoft’s WSL2 ships a Microsoft-maintained Linux kernel (the WSL2 kernel repository is public and Microsoft publishes guidance for using their kernel). The critical follow-up question is whether Microsoft’s WSL2 kernel builds enable CONFIG_KASAN. Public inspection of typical Microsoft/WSL kernel configs shows KASAN is not set in mainstream WSL kernel builds (the sample config snippets and several WSL kernel config gists indicate “# CONFIG_KASAN is not set”). That means WSL2 kernels distributed to Windows users are normally not compiled with KASAN and therefore would not be affected by a KASAN-specific bug — but operators should verify the exact kernel config for their shipped WSL kernel if they use custom or experimental kernels.

So: while other Microsoft projects technically could include the same open-source files, Microsoft’s public inventory at the time of publication lists Azure Linux only, and public evidence shows WSL2’s official kernels typically do not enable KASAN. That supports Microsoft’s wording and explains why they have named Azure Linux specifically while reserving the right to update the CVE mapping later.

---

Independent corroboration and technical verification​

Key cross-checks performed while preparing this analysis:

• The NVD and major vendor trackers catalog the CVE and point to upstream kernel stable commits that implement the fix; the NVD entry outlines the apply_to_pte_range/kasan_populate_vmalloc_pte issue and references upstream commits.
• Kernel mailing-list threads and patchew postings show the upstream patch series and reviewers, and they explain the exact code change (switching small allocations to atomic allocation context or pre-allocating shadow pages in bulk) that prevents sleeping in atomic contexts. These patches were accepted into the upstream and stable trees.
• Public trackers and vendor advisories emphasize the operational impact is availability-focused and that remediation is to install patched kernels that include the upstream commits. That matches Microsoft’s guidance to keep Azure Linux up to date.
• Microsoft documentation and community guidance for WSL show Microsoft-published kernel images and configs; publicly available WSL kernel configs sampled from users and build gists show KASAN disabled in typical Microsoft WSL binaries. That reduces the likelihood WSL is affected in normal configurations, but custom WSL kernels built by users or experimental kernels could differ.
• Internal operational writeups (uploaded vulnerability-tracker snippets and operational guidance captured in the accompanying security thread files) emphasize the need for inventory, staged rollout, and monitoring in production — consistent with standard kernel CVE remediation practice.

---

Practical risk assessment for Microsoft customers and operators​

1. If you run Azure Linux images or Azure-managed services that use Azure Linux kernels
   • Treat this as a confirmed mapping: patch the kernel packages Microsoft ships for Azure Linux as soon as Microsoft publishes the fixed kernel packages or images. Microsoft’s advisory explicitly covers Azure Linux as a product mapped to the CVE.
2. If you run WSL2 on Windows
   • Check which kernel you are using. The official Microsoft WSL kernel images typically have KASAN disabled, meaning the KASAN-specific CVE would not apply to those binaries. However, if you are using a custom WSL kernel (by setting kernel= in .wslconfig) or an experimental Microsoft kernel build that explicitly enables KASAN, you must verify the kernel configuration and apply upstream fixes (or rebuild without KASAN) as appropriate. Do not assume all WSL kernels are immune; verify the config.
3. If you operate other Microsoft-supplied or -managed Linux kernels (images, appliances, platform services)
   • Work under the principle of “inventory first”: identify which deployed kernels are built with KASAN enabled. A quick method: inspect /boot/config-$(uname -r) or the kernel .config used to build the binary and grep CONFIG_KASAN. Systems with CONFIG_KASAN=y are in scope. If you do not control the image (for example, a managed PaaS offering), consult the vendor advisory or contact the platform team.
4. If you vendor or embed kernels (partner appliances, OEM images)
   • Embedded or long-tail vendor kernels are often the slowest to receive backports. If you maintain images that include a Linux kernel with KASAN enabled, you should prioritize mapping upstream commit IDs to your kernel packages and plan for backporting or rebuilding images. Public trackers list the upstream commits — use them to verify vendor package mapping.

---

Recommended checklist and remediation steps (operational playbook)​

1. Inventory
   • Identify all hosts that run Linux kernels under your control. Query uname -r and /boot/config-$(uname -r). Look specifically for CONFIG_KASAN or KASAN variants: grep -i kasan /boot/config-*. If CONFIG_KASAN=y the host must be treated as in-scope.
2. Vendor mapping
   • For Azure Linux, monitor Microsoft’s package or image updates; install the vendor-supplied updates as published. Microsoft promised to update the CVE mapping if other Microsoft products are affected — monitor the MSRC update page and your Azure advisories.
3. Patch and test
   • Obtain the patched kernel package or upstream commit that contains the kasan-populate-vmalloc fix. Deploy to a pilot group, validate workloads, and then proceed with staged rollouts.
4. Reboot
   • Kernel fixes require a reboot to remove the vulnerable code from running memory. Schedule maintenance windows accordingly.
5. Monitor
   • After patching, monitor kernel logs (dmesg, journalctl -k) for “sleeping function called from invalid context” or related oops traces. Maintain monitoring for at least 7–14 days post-deploy to catch intermittent triggers.
6. Containment (if you cannot patch immediately)
   • Reduce exposure: restrict access to the features that may trigger the code path (for example, reduce use of vmalloc-heavy or page-table-walking workloads on debug kernels, or limit untrusted kernels/VMs). Quarantine or move sensitive workloads to patched hosts.
7. Special-case review
   • If you use WSL with a custom kernel or run non-mainstream kernels (e.g., debug kernels, fuzzing images), explicitly verify their configs and rebuild without KASAN if the build does not need it.

Numbered action list (condensed):

1. Find kernels with CONFIG_KASAN enabled.
2. Map the kernel package to upstream commits referenced by CVE trackers.
3. Apply vendor/patch updates that include the upstream fix.
4. Reboot into the patched kernel.
5. Monitor kernel logs and behavior for regressions.

---

Strengths of the upstream fix — and residual risk​

The upstream change is surgical and minimal. It preserves existing semantics while restoring the kernel contract that code running in atomic contexts must not sleep. Because the change is a context/allocation-mode correction rather than a rewrite of functionality, it is low-risk for regressions and easy to backport into stable kernels. That is why distributors have rapidly added the stable commits to their security packages. Residual risk factors to watch:

• Debug vs production kernels. KASAN is commonly used in debug/fuzzing kernels; if your estate includes debug kernels in production by mistake (a surprisingly common operational mistake), those hosts are more exposed.
• Vendor/custom kernels. Appliances, OEM images, and vendor-managed kernels may lag upstream and need vendor-specific backports, which creates a remediation tail.
• Unverified assumptions. Never assume a product is safe simply because a vendor has not listed it; verify kernel configs and inventory. Microsoft’s advisory reflects their inventory at the time — they will update the CVE mapping if further products are found to contain the impacted code.

---

Conclusion — clear takeaways for operators and Microsoft customers​

• Microsoft’s public advisory identifies Azure Linux as the Microsoft product that includes the affected open-source kernel code tied to CVE-2025-38029; Microsoft has pledged to update the CVE if additional product mappings are discovered.
• The vulnerability is an upstream Linux-kernel KASAN-path correctness issue that causes sleep-from-atomic crashes; the upstream patch is a small, targeted change and has been merged into stable trees for downstream packaging.
• In practical terms, the universe of actually affected hosts is limited to systems running kernels built with CONFIG_KASAN (or otherwise containing KASAN code). Most production kernels do not enable KASAN, but operators should verify their inventories rather than assume immunity.
• If you run Azure Linux, apply Microsoft’s kernel updates promptly when they are published. If you run WSL2 with Microsoft’s official kernels, those kernels typically have KASAN disabled, but if you or your users run custom WSL kernels or debug kernels, check the kernel config and update accordingly.
• Prioritize the standard remediation workflow: inventory, vendor mapping, staged patching, reboot, and close monitoring. This CVE underscores the broader operational lesson that small context/ordering bugs in privileged code paths can produce outsized availability risk and therefore deserve prompt remediation even in the absence of a public exploit.

---

Operational guidance and references used in this analysis were drawn from public vulnerability trackers, upstream kernel mailing-list posts and stable commits, Microsoft’s advisory page, published guidance on WSL kernels and kernel-config inspection, and internal operational briefings captured in vendor/incident threads. Those materials collectively support the assessment that Azure Linux is the Microsoft product already identified as including the vulnerable library, that other Microsoft products are not currently confirmed by Microsoft to include it, and that the path to remediation is straightforward: apply patched kernels that incorporate the upstream fix and verify kernel configurations across your estate.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center