CVE-2025-38206 ExFAT Double Free: Azure Linux Attestation Explained

Microsoft’s short MSRC line that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate — but it is a scoped, product‑level attestation rather than a blanket guarantee that no other Microsoft product could contain the same vulnerable exFAT code. erview
In July 2025 the Linux kernel community assigned CVE‑2025‑38206 to a double‑free bug in the in‑kernel exFAT implementation. The defect arises during upcase table handling: under a particular error path the kernel ends up calling the exfat upcase table free routine twice, which can corrupt heap metadata and lead to crashes or other memory‑corruption outcomes. The upstream remedy sets the freed pointer to NULL immediately after the free to prevent the second free.
For operators this looks like a classic local denial‑of‑service / memory‑corruption flaw: the attack vector is local (the attacker must be able to provoke the kernel code path, typically by mounting or interacting with a crafted exFAT image) and the practical impact is availability and potential, though not demonstrated, memory corruption leading to higher‑risk outcomes on some allocators. Multiple distro advisories and vulnerability trackers recorded the fix and backports into stable kernels.
Microsoft’s Security Response Center (MSRC) responded in the now‑familiar way it has used for several Linux kernel CVEs: publish a concise product attestation saying Azure Linux includes the implicated open‑source library and therefore is potentially affected, and to expand CSAF/VEX attestations to additional Microsoft products over time. That one‑line FAQ answer is precise and actionable for Azure Linux customers — but readers frequently misread it to mean “Azure Linux is the onlhat could be affected.” It is not.

---

What CVE‑2025‑38206 actually is — technical anatomy​

The vulnerable path​

At the code level, the double free happens in the exFAT upcase‑table lifecycle. The sequence looks like:

• exfat_create_upcase_table() encounters an error and calls exfat_free_upcase_table() which frees ->vol_utbl;
• later, as part of shutdown/cleanup (exfat_kill_sb() -> delayed_free()), the delayed cleanup path calls exfat_free_upcase_table() again against the same pointer;
• because the first free did not null the pointer in all error paths, the second free re‑frees the same memory region — a double free. The upstream patch explicitly sets the pointer to NULL after freeing it to cut that path.

Why the fix is minimal and effective​

The upstream change is small and defensive: set ->vol_utbl (or analogous pointer) to NULL immediately after freeing it. This prevents further attempts to free an already freed pointer in later teardown phases. That pattern — free-then-null — is a well‑understood defensive idiom for single‑threaded cleanup logic and resolves the immediate double‑free symptom without broad behavioral change. Patch commits and stable backports were committed to several kernel series.

Realistic impact profile​

• Attack vector: Local — mounting or causing the kernel to process a crafted exFAT image or provoking the upcase table error path.
• Primary impact: Availability / system crash; possible memory corruption if heap metadata is corrupted in exploitable ways depending on allocator and platform.
• Exploit evidence: As of this writing, no public weaponized exploit has been demonstrated; vendor trackers categorize the problem as a robustness/DoS risk but rightly flag memory corruption as non‑trivial.

---

Microsoft’s MSRC wording: what it says and what it means​

Microsoft’s CVE FAQ phrasing for several Linux kernel CVEs — including the exFAT issue in question — has been a short, consistent sentence: “Azure Linux includes this open‑source library and is therefore potentially affected.” Microsoft published a program to release machine‑readable CSAF/VEX attestations beginning in October 2025 and states it will update product mappings as more artifacts are verified. That is the core of the MSRC meally useful for Azure Linux customers.
But two important clarifications follow immediately:

• Product‑scoped attestation is an authoritative yes for the named product (Azure Linux). If you run Azure Linux images, treat them as in‑scope and apply Microl updates as soon as they are available.
• Product‑scoped attestation is not a universal exclusivity claim. Saying Azure Linux includes the component does not prove that no other Microsoft artifact (WSL kernels, linux‑azure builds, Marketplace images, AKS node images, management appliances, agent bundles, or partner images) could carry the same upstream code. Absence of a Microsoft attestation for product X is absence of attestation — not evidence that product X is clean.

---

Is Azure Linux the only Microsoft product that includes this open‑source library and is therefore potentially affected?​

Short answer: No — Azure Linux is the only Microsoft product Microsoft has publicly attested so far to include the vulnerable exFAT code for this CVE, but that attestation is product‑scoped, not an exclusivity guarantee. Until Microsoft publishes VEX/CSAF attestations for other product families, those artifacts remain unverified and should be inventoried by operators.

Why that distinction matters (technical reasons)​

Whether a given Microsoft artifact includes the vulnerable exFAT code depends on three concrete, verifiable facts for the kernel binary that underpins the artifact:

• Kernel source snapshot / commit used to build the image (did the build include the unpatched upstream commit?). Distribution vendors backport fixes; a build made before the backport could still be vulnerable.
• Kernel configuration used at build time (is exFAT built in or modularized?). The kernel configuration symbol for the in‑tree exFAT driver is CONFIG_EXFAT_FS (and in older trees a staging variant existed as CONFIG_STAGING_EXFAT_FS). If a kernel was built without CONFIG_EXFAT_FS enabled, the exFAT code will not be present in that kernel binary. That fact is binary‑verifiable.
• Vendor backports and local patches: a vendor may have applied a fix to a stable branch at build time. Conversely, a vendor could ship an older kernel snapshot without the upstream fix. The presence or absence of the patch must be confirmed by mapping a shipped kernel version to the upstream stable commit that fixed the issue.

Because Microsoft ships multiple kernel artifacts and images — WSL2 kernels for Windows, linux‑azure kernels for some VM SKUs, Marketplace images, AKS node images, and thin‑image appliances — any of those could carry exFAT depending solely on the three facts above. Microsoft’s initial VEX/CSAF rollout simply began with Azure Linux because it is a single, tractable product family to inventory and attest.

---

Practical verification: how to confirm whether a given Microsoft artifact includes the vulnerable exFAT code​

If you operate environments that consume Microsoft artifacts, perform artifact‑level verification. Below are pragmatic, verifiable steps.

1) Identify the kernel binary for the artifact​

• For VMs and images: boot a test instance or extract the image and read the kernel package metadata (the package name, version).
• For WSL2 kernels: check the kernel binary distributed to WSL (you can query the WSL kernel version from inside WSL or inspect the kernel binary shipped by Microsoft).
• For containers or Marketplace images: examine the packaged kernel or, more commonly, the base image metadata for the kernel package name.

2) Check whether exFAT support was compiled into that kernel​

• Run (on the running instance or from the image) one of:
• grep CONFIG_EXFAT_FS /boot/config-$(uname -r)
• zcat /proc/config.gz | grep CONFIG_EXFAT_FS
• cat /proc/config.gz 2>/dev/null | grep CONFIG_EXFAT_FS
  If the symbol is set to y or m, the exFAT code is present (built‑in or module). The kernel config symbol name is CONFIG_EXFAT_FS.
• Alternatively, check for an exfat module: modinfo exfat or lsmod | grep exfat.

3) Map the kernel version to the upstream patch​

• Obtain uname -r (kernel release) and then map that release to the distro’s kernel package and changelog. Look up the distro advisory (Ubuntu, SUSE, Red Hat, Amazon Linux) to see whether the kernel package includes the CVE fix or whether a backport was applied. The OSV / distro advisory feeds are the right place to confirm.

4) If you cannot boot or access the image, perform offline inspection​

• Mount the image and inspect /boot/config-*- or package metadata in the image. You can also extract the kernel binary and compare function symbols for the presence of the patched routine, or run strings/objdump-based checks for specific commit markers if your security tooling supports it.

5) Useere available​

• Ingest vendor VEX/CSAF attestations and SBOMs into your vulnerability‑management pipeline. Microsoft has begun publishing VEX attestations for Azure Linux and plans to expand that coverage; where a product-level VEX exists it can be consumed to automate decisions. But when no VEX exists for an artifact you still need to verify manually.

---

Operational recommendations and prioritized remediation checklist​

Below are concrete, prioritized actions for system administrators and security teams.

Immediate (first 24–72 hours)​

• If you run Azure Linux: treat Microsoft’s attestation as authoritative and patch immediately using Microsoft’s updated packages or follow the Azure Linux security notice. Azure Linux images were explicitly attested and should be remediated first.
• For any host known to mount untrusted exFAT images (CI runners, user-uploaded images, VM templates, CI/CD artifacts, file‑upload services): isolate and schedule patching; avoid mounting untrusted exFAT images until patched.
• Search logs (dmesg, journalctl) for exfat‑related oops or BUG traces indicating exfat_free_upcase_table or related symbols; treat any matches as actionable forensic artifacts.

Near term (1–2 weeks)​

• Inventory Microsoft‑supplied artifacts you consume: WSL kernels, AKS node images, linux‑azure kernels, Marketplace images, partner appliances. For each artifact determine kernel version and whether CONFIG_EXFAT_FS is set; treat those that include exFAT and lack a confirmed vendor fix as unverified and remediate.
• Automate mapping of kernel versions to upstream fixes. Use distro advisories (Ubuntu USN, SUSE bulletins, Amazon ALAS, etc.) and the NVD/OSV feeds to programmatically determine which kernel package releases contain the fix.

Medium term (weeks to months)​

• Integrate SBOM and VEX ingestion into your vulnerability management pipeline so vendor attestations become first‑class signals for triage. Microsoft’s CSAF/VEX rollout for Azure Linux is an example of how this reduces ambiguity — but you must accept that not every vendor artifact will immediately be covered.
• Harden image supply chains: sign images, restrict which images can be mounted by shared services, and implement admission controls for block devices and mount operations in multi‑tenant platforms.

---

Why Microsoft’s attestation model is helpful — and where it leaves gaps​

Microsoft’s adoption of CSAF/VEX and the public attestation that Azure Linux contains the implicated library is a step forward for transparency: it gives customers an authoritative, machine‑readable answer for a named product and makes automated triage easier. For Azure Linux customers, the MSRC entry is the signal to act now.
That said, supply chains are messy. Large vendors ship many disparate artifacts, and kernel code can reappear in images and appliances in ways that are not trivially enumerated. A single per‑product answer cannot prove the absence of a vulnerable library from other product families. In other words: the attestation is necessary, but not sufficient, to determine global exposure across a vendor’s entire artifact footprint.

---

How exploitability could evolve — what to watch for​

• Allocator behavior changes across kernel releases or platforms could change a local double free from a DoS to something more dangerous in a different environment. Track vendor‑specific allocator versions and kernel ABI changes if you run custom kernel builds.
• Evidence of a weaponized exploit will likely appear first in targeted intrusion reports or exploit databases; stay alert to new advisories and to exploit telemetry that referencehe exfat_free_upcase_table symbol.

---

Summary and takeaways​

• CVE‑2025‑38206 is a resolved double‑free in the Linux in‑kernel exFAT implementation. The upstream fix sets the freed pointer to NULL to prevent a second free in delayed cleanup. Vendor advisories (Ubuntu, SUSE, Amazon Linux, others) track the fix and list package updates.
• Microsoft’s MSRC message that “Azure Linux includes this open‑source library and is therefore potentially affected” is a clear, authoritative attestation for Azure Linux — and Azure Linux customers should remediate first. However, that statement is product‑scoped and does not prove that other Microsoft products are unaffected. Treat un‑attested Microsoft artifacts as unverified and verify them using the kernel‑level checks above.
• Practical steps: patch Azure Linux immediately; inventory other Microsoft artifacts (WSL2, linux‑azure, Marketplace images, AKS nodes); check kernel configs for CONFIG_EXFAT_FS; map kernel versions to upstream patch commits; and ingest vendor VEX/CSAF attestations and SBOMs to reduce triage time.

Microsoft’s phased VEX/CSAF rollout is useful and will reduce ambiguity over time. Until their attestations cover all product families you use, the safest operational posture is: assume any Microsoft‑delivered Linux kernel or image you rely on could be a carrier, confirm presence or absence by inspection, and patch or isolate accordingly.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center