CVE-2025-38384: Linux Spinand Driver Memory Leak Fix and Azure Linux Attestations

The Linux kernel patch for CVE-2025-38384 fixes a small but real memory-leak in the MTD spinand driver: configuration memory allocated for the ECC engine was not freed during spinand cleanup, producing persistent kmemleak traces and a repeated, host-level availability risk until the driver was patched. This is a robustness/availability defect rather than a remote code-execution or confidentiality vulnerability, but it is meaningful for systems that load the spinand driver (for SPI-NAND flash) or run long-lived workloads where kernel memory leaks can accumulate and destabilize hosts.

Background​

CVE-2025-38384 was disclosed in July 2025 and recorded across mainstream vulnerability databases and distribution trackers. The defect sits in the MTD (Memory Technology Device) subsystem’s spinand driver: memory allocated for the ECC engine configuration was not released during the driver’s cleanup path. The issue was observed in kmemleak traces as small (8‑byte) unreferenced allocations originating from spinand probe/cleanup call paths. Upstream maintainers fixed the problem by ensuring nanddev_ecc_engine_cleanup is invoked during spinand_cleanup, removing the orphaned allocation. Why this matters operationally

• Kernel memory leaks are an availability risk: small leaks can accumulate on long‑uptime systems, test farms, CI runners, and multi‑tenant hosts, ultimately triggering memory pressure, OOM conditions, or crashes.
• The vulnerability requires local code execution or device attachment privileges to exercise the spinand probe/cleanup paths (the typical attack surface is local or device-directed), which shapes the threat model: not a remote wormable issue, but still a production reliability hazard.

What Microsoft said — the wording that prompted this question​

Microsoft’s Security Response Center has begun publishing machine-readable CSAF and VEX attestations and, for many kernel-related CVEs, includes a concise product-level statement along the lines of: “Azure Linux includes this open-source library and is therefore potentially affected by this vulnerability,” with a follow-up promise to update the CVE/VEX mappings if additional Microsoft products are later discovered to ship the component. That phrasing is deliberate: it declares what Microsoft has inventory-checked and attested so far rather than asserting exclusivity. Microsoft’s approach began as a phased rollout that started with Azure Linux (the company’s Linux distribution lineage derived from CBL-Mariner) to provide clear, machine-readable attestations to customers and security tooling. The key operational implication is that Azure Linux is the only Microsoft product Microsoft has publicly attested for many of these CVEs at rollout time — and that Microsoft will expand attestations as it inventories more products.

---

Short answer to the user’s question​

No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable spinand code or be affected by CVE-2025-38384. What Microsoft’s advisory does tell you is this: Azure Linux is the Microsoft product Microsoft has inspected and attested so far and therefore should be treated as a confirmed carrier that requires remediation. Absence of a Microsoft VEX/CSAF attestation for another Microsoft product is not proof that the product is free of the vulnerable code; it simply means Microsoft has not yet published a product-level inventory result for that artifact.

Why that one-line answer matters​

• Attestations are product‑scoped, not global guarantees. A vendor attestation that a specific product includes a component means inventory work was done for that product and it was found there. It does not imply a negative for other products unless the vendor states those other products explicitly.
• Kernel inclusion is an artifact-level property. Whether a Microsoft-supplied kernel or image includes a particular driver depends on the kernel version, the exact upstream commit range used, and the kernel configuration flags (CONFIG_*) used at build time. Two Microsoft kernel artifacts can therefore differ in whether they include spinand.
• Microsoft distributes multiple Linux-related artifacts. In practice, Microsoft maintains and ships several Linux artifacts beyond Azure Linux — for example, WSL2 kernel builds, linux-azure kernels used for some VM families, curated Marketplace images, AKS node images, and partner Marketplace appliances. Any of those artifacts could, in principle, include the vulnerable spinand code if they were built from an upstream range that contained the bug and included the driver in the kernel config.

---

Technical verification: cross-checking the facts​

To anchor the analysis in public facts, the vulnerability description, kmemleak trace, and remediation commit are recorded in multiple independent trackers:

• NVD and OSV record the kernel-level description: the spinand ECC engine conf allocation was not freed in the cleanup path; calling nanddev_ecc_engine_cleanup inside spinand_cleanup removes the leak. This is a straightforward upstream fix.
• Major distributions published advisories mapping the fix into their kernels (Ubuntu published advisory details and priority, SUSE and Debian tracked the issue and package updates). This confirms the upstream remedy landed and was pushed to downstream kernel packages.
• Independent vulnerability databases (Wiz, Rapid7) provide technical context and a risk assessment consistent with a local/availability impact. These independent sources corroborate the technical summary and confirm no public remote RCE exploit has emerged for this leak as of their updates.

Because the technical details are kernel-level and the remediation is an explicit cleanup call, the fix is low-risk and suitable for backporting to stable branches — which is reflected in distribution advisories. Those package mappings are the canonical way administrators determine whether their installed kernel package includes the fix.

---

Practical implications for Microsoft customers and IT teams​

What to assume and prioritize​

• Assume Azure Linux is affected if you run Azure Linux images or kernels — Microsoft has attested this product. Treat Microsoft’s VEX/CSAF attestation for Azure Linux as the canonical signal for that product and apply the vendor’s remediation guidance immediately.
• Assume uncertainty for other Microsoft artifacts until you confirm at the artifact level. Do not treat Microsoft’s attestation for Azure Linux as proof other Microsoft images (WSL kernel, linux-azure, Marketplace images, AKS node images) are unaffected. Inventory those artifacts and verify kernel versions and configs.

Concrete verification steps (recommended)​

1. Inventory all Microsoft-supplied Linux artifacts in your estate:
   • Azure VM images, Marketplace images, AKS node images, WSL2 kernels, and linux-azure kernels.
2. For each artifact, determine:
   • The exact kernel version or package build number.
   • The kernel configuration (CONFIG_MTD, CONFIG_MTD_SPI_NAND, CONFIG_SPINAND and related ECC engine flags) used to build the kernel; this may indicate whether the spinand driver was compiled in or as a module.
3. Cross-check kernel version against distribution or vendor advisories for CVE-2025-38384 and confirm whether the kernel package changelog references the upstream fix or a backport.
4. Use SBOMs, SCA scans, binary inspection, or package metadata to identify the presence of the spinand code or the affected driver module in images and kernels.
5. If a Microsoft product artifact is found to carry the vulnerable driver and has no published VEX/CSAF attestation, escalate to Microsoft support or treat it as "under investigation" and apply mitigations/patches per your change control.

Detection and temporary mitigations​

• Monitor kernel kmemleak reports and slab memory trends on long-lived hosts; anomalous, reproducible kmemleak traces involving spinand stack frames are definitive evidence the code path was executed.
• If the environment does not require SPI‑NAND support, consider blacklisting the spinand module (modprobe.blacklist=spinand) as a short-term mitigation until you can apply a patched kernel. This prevents probe paths that would trigger the now-fixed allocation/cleanup sequence.
• Enforce least privilege on hosts that expose device attach operations or allow untrusted tenants to perform device-level requests; limit who can perform ioctls or attach devices that would provoke spinand probe/cleanup cycles.

---

Why Microsoft named Azure Linux first (practical context)​

Microsoft’s VEX/CSAF rollout began as a pragmatic, phased program; Azure Linux was chosen as the initial product family because it is the Microsoft-published Linux distribution and therefore the easiest to inventory and attest at scale. Publishing attestations product-by-product provides deterministic automation signals to customers — an attestation for Azure Linux is authoritative for that product, but it’s only one product among many that Microsoft maintains. Microsoft’s published blog explains this phased approach and why an initial focus on Azure Linux improves clarity for customers while inventorying other artifacts. This rollout method is common across large vendors that ship many images, kernels, containers, and appliances: start with a single, well-scoped product, publish machine-readable attestations, and expand the mapping as inventory work completes. The presence of that explicit vendor promise to update CVE mappings if additional products are later identified is an important procedural safeguard — but until Microsoft publishes additional VEX attestations for other products, those products remain unverified.

---

Risk analysis — strengths and limitations of Microsoft’s statement​

Strengths (what Microsoft’s statement does well)​

• Actionable clarity for Azure Linux customers. Customers using Azure Linux have an immediate, machine-readable signal that their product is a confirmed carrier and must be remediated.
• Machine-readable VEX/CSAF output enables automation. Automated triage, patch orchestration, and compliance checks can consume Microsoft’s attestations to focus resources quickly.
• Commitment to broaden attestations. Microsoft’s public commitment to update the CVE/VEX entries if additional products are found to be carriers provides a clear escalation path and accountability for customers.

Limitations and risks​

• Attestation ≠ exhaustiveness. The statement focuses on inventory work done so far; it does not prove other Microsoft artifacts are unaffected. Misreading the advisory as “only Azure Linux is affected” is a dangerous false negative for asset owners.
• Artifact variance across Microsoft offerings. Microsoft ships multiple kernel artifacts that may differ in kernel config, feature set, and build provenance; each artifact requires independent verification.
• Operational gap while inventory continues. Until Microsoft completes broader attestations, customers must do artifact-level checks themselves; that extra work is operational overhead that introduces windows of uncertainty in large estates.

---

Recommended remediation playbook (step-by-step)​

1. For Azure Linux images:
   • Apply Microsoft’s published updates for kernels and images immediately and schedule reboots where required. Use Microsoft’s VEX/CSAF attestations as the authoritative automation source for patch state.
2. For other Microsoft-supplied artifacts (WSL, linux-azure kernels, Marketplace images, AKS nodes):
   • Run an inventory and confirm kernel versions / configs.
   • If you find an unpatched artifact that includes the spinand driver, treat it as “potentially affected” pending vendor confirmation; patch or rebuild the artifact with a fixed kernel.
3. For on-prem or third-party images:
   • Scan images and kernels with SBOM/SCA tooling to detect the presence of the vulnerable driver or kernel versions mapped to the upstream fix. Rebuild images where necessary.
4. Short-term mitigations:
   • Blacklist spinand when not required; limit device attach capabilities and enforce strict container capability profiles.
   • Monitor kmemleak and kernel slab growth across critical hosts; treat anomalous growth as a high-priority investigation item.
5. Communications:
   • Notify platform and patch teams, and if you operate multi-tenant services, prioritize hosts where untrusted tenants can exercise device operations or attach devices.

---

Final verdict and closing guidance​

CVE-2025-38384 is a verifiable Linux kernel memory-leak fix in the spinand driver; multiple independent trackers (NVD, Ubuntu, SUSE, Debian/OSV and third‑party vulnerability databases) document the same description and remedial commit. Microsoft’s statement that “Azure Linux includes this open-source library and is therefore potentially affected” is an accurate, product-scoped attestation: treat Azure Linux as a confirmed carrier and apply Microsoft’s patched kernel images immediately. However, do not infer exclusivity from Microsoft’s attestation. Azure Linux is the product Microsoft began with for VEX/CSAF attestations; absence of attestations for other Microsoft artifacts does not prove those artifacts are clean. For thorough assurance, inventory every Microsoft-supplied kernel/image you run, confirm kernel build provenance and config, and apply the upstream/distribution fixes where needed. Use SBOMs, kernel config checks, and targeted image rebuilds to eradicate lingering vulnerable artifacts and treat vendor attestations as authoritative only for the exact products they name. The combination of vendor-provided VEX/CSAF attestations (for automation) and per-artifact verification (for coverage) is the defensible approach: act urgently where Microsoft has attested, and verify everywhere else.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center