Azure Linux HFS+ CVE 2025: Understanding Attestations and Risk Beyond Azure

Microsoft’s concise public answer — that “Azure Linux includes this open‑source library and is therefore potentially affected” — is accurate, but it is a scoped, product‑level attestation and should not be read as proof that Azure Linux is the only Microsoft product that could ship the vulnerable HFS+ code. Microsoft’s VEX/CSAF program rollout began with Azure Linux and the company has said it will update CVE mappings if additional Microsoft products are found to include the same upstream component. 38713 is a kernel vulnerability discovered in the Linux HFS Plus (hfsplus) filesystem implementation. The root cause is a slab out‑of‑bounds read in the symbol hfsplus_uni2asc(), which can be triggered via the hfsplus_readdir() path when the kernel reads directory entries from an HFS+ volume. The upstream kernel team merged targeted fixes into the stable trees and assigned the CVE on 4 September 2025.
This vulnerability is, at core, a Linux kernel filesystem bug. That means any product or image that ships a Linux kernel build with the HFS+ code enabled (either built-in or as a loadable module) may be affected until the kernel has been updated or the vulnerable driver is disabled. Multiple Linux distributions and vendors tracked and remediated this issue in their kernels shortly after the upstream fix; for example, Amazon Linux and other major distros published advisories mapping the fix into their kernels.

---

What Microsoft actually said — and what that wording means​

Microsoft’s publicly visible advisory text for this and multiple similar Linux kernel issues has followed a consistent pattern: the company confirms that Azure Linux includes the upstream component and therefore “is potentially affected”, and it has begun publishing machine‑readable CSAF/VEX attestations (a phased rollout that started in October 2025) for Azure Linux to provide automation‑friendly inventories. Microsoft also promises toapping in the event additional Microsoft products are confirmed to ship the vulnerable code.
Put simply:

• The statement is an authoritative inventory result for the product named (Azure Linux).
• The statement is not an exclusivity guarantee for all Microsoft products.
• Microsoft’s planned approach is tattestations when other products are positively identified as carriers.

This distinction matters for defenders: a product‑scoped VEX is extremely useful if you operate that product (it lets you automate triage and mitigation). It is not automatic evidence that other Microsoft images, kernels, or appliances are clean.

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No — not necessarily.
Long answer: Microsoft has publicly attested Azure Linux as a confirmed carrier for the upstream HFS+ code in the context of the CVE and has begun publishing CSAF/VEX for Azure Linux, but the presence of the vulnerable code in other Microsoft artifacts is an operational question. Any Microsoft product or artifact that:

• ships a Linux kernel build that includes the HFS+ filesystem driver, or
• distributes kernels or images that were built from upstream branches where the vulnerable code is present,

could be affected until that artifact is individually inventoried and patched. That includes, in scope or in practice:

• Azure Marketplace VM images and platform images that use Microsoft’s Azure Linux kernels (or that embed kernels compiled with the HFS+ driver enabled);
• Microsoft‑built kernel images such as the WSL2 kernel (Windows Subsystem for Linux ships a Microsoft‑maintained Linux kernel for WSL2 on many systems);
• Azure Kubernetes Service (AKS) node images or other managed images that either run Microsoft‑provided kernels or are built from those kernels;
• Any other Microsoft appliance or distribution that bundles a Linux kernel (on premises or cloud images) and does not explicitly exclude the HFS+ code at build time.

Multiple community analyses and vendor attestations for other Linux kernel CVEs have used the same logic: Microsoft’s published attestation narrows immediate, authoritative scope to Azure Linux, but it does not eliminate the practical possibility of other Microsoft artifacts carrying the same upstream code until each artifact is checked.
Key points to understand:

• A VEX/CSAF attestation is a product inventory statement — it confirms what Microsoft has checked and published, not everything Microsoft may ever ship.
• The Linux kernel is upstream shared code: the same hfsplus source file (fs/hfsplus/unicode.c) sits in upstream trees and flows into many downstream kernels and distributions. If Microsoft builds any kernel using a source tree that included the vulnerable version of that file, that build may carry the vulnerability.
• Therefore, Azure Linux being attested does not imply other Microsoft kernel images (WSL, AKS nodes, custom images) are safe until they are either listed in the VEX or inspected by your own SBOM/kernel config checks.

---

Why this nuance matters to customers and defenders​

• Azure Linux customers can immediately rely on Microsoft’s attestation to automate triage of Azure Linux instances and apply the fixes or updates Microsoft recommens an important operational benefit and it reduces time to mitigation for that product.
• Organizations that also run Microsoft‑provided artifacts beyond Azure Linux (for example WSL instances on Windows clients, internal images built from Microsoft kernels, or AKS node pools with Microsoft images) must treat each artifact as a separate risk domain: the presence of HFS+ code is a per‑artifact, build‑time property. Until Microsoft specifically attests those artifacts, or you validate them yourself, you should assume they are unverified for this particular upstream vulnerability.
• Attack vectors: because this CVE is triggered by filesystem operations against an HFS+ volume, attackability depends on whether an attacker can cause the target kernel to read from a crafted HFS+ filesystem (for example by mounting an attacker‑controlled image). That means the attack is generally local (or requires file image exposure to the target), not a generic remote network exploit — but local exposures on shared systems, multi‑tenant VMs, or where untrusted block images can be attached are important threat models to consider. The upstream technical notes and KASAN calltrace confirm an out‑of‑bounds read and a crash being possible via readdir paths.

---

Evidence: what the public sources show​

• Upstream Linux kernel announce (Linux CVE announce): the vulnerability, the affected file (fs/hfsplus/unicode.c), a sample KASAN trace, and the upstream commits that fix the issue. This provides the technical ground truth for what changed in the kernel.
• Distribution advisories: multiple distributions and vendors mapped the CVE into their kernel advisories and published fixes (for example Amazon Linux and others listed fixed kernel releases), showing the typical downstream remediation path. These advisories prove the fix is in stable kernels and that distro shipping kernels were updated.
• Microsoft statements as aggregated in the public conversation and the MSRC approach: Microsoft confirmed Azure Linux includes the open‑source library and announced it would publish CSAF/VEX attestations starting with Azure Linux (October 2025), with a promise to update CVE entries if impact to additional products is found. That is Microsoft’s published process for scaling machine‑readable inventory.

Together, these sources establish (1) the nature of the bug and its upstream fix, (2) downstream distribution remediation activities, and (3) Microsoft’s attestation practice and limits.

---

Practical guidance: how to determine whether your Microsoft artifacts are affected​

You must treat this as an artifact‑level question. The steps below are a practical playbook that will let you confirm whether a given Microsoft image or kernel build includes vulnerable HFS+ code.

1) Start with the Microsoft attestations (CSAF/VEX)​

• If Microsoft has publa specific product (for example, Azure Linux), treat that as authoritative for that product and follow Microsoft’s remediation guidance. Microsoft’s VEX for Azure Linux is precisely intended to make automated triage possible.

2) For any other Microsoft artifact you operate (WSL, AKS nodes, Marketplace VM images, Windows with WSL2)​

• Inspect the kernel shipped with that artifact. You need to know whether the kernel build included the HFS+ driver source or configuration.

How to check (typical commands you can run on a Linux VM or on WSL):

• Check if the HFS+ module/built‑in is present:
• lsmod | grep -i hfs
• modinfo hfsplus
• zgrep CONFIG_HFSPLUS /proc/config.gz
• grep -i hfsplus /boot/config-$(uname -r)
• If running WSL or a Microsoft-supplied kernel, check the kernel version and the kernel configuration shipped with that WSL kernel. WSL maintains a kernel build for WSL2 on many systems — check the WSL kernel version and update path for your Windows version to determine whether that kernel uses upstream sources that included the vulnerable HFS+ code. (If you see CONFIG_HFSPLUS=y or m, the driver is present and should be considered in scope.)
• If your environment uses prebuilt images (AKS node images, Marketplace images, appliances), treat those as opaque artifacts until you can inspect them. Ask Microsoft for a VEX or SBOM for that specific image, or extract the VM’s kernel and check the kernel config / modules as above.

Note: You do not need to run grep commands on every image if Microsoft has issued a VEX confirming the artifact is not affected. But absent a VEX, self‑inspection is the only authoritative route.

3) Temporary mitigations while you verify or patch​

• If you do not need HFS+ support on affected systems, unload and blacklist the HFS+ module:
• sudo modprobe -r hfsplus
• Add blacklist hfsplus to /etc/modprobe.d/blacklist.conf (or the distro equivalent).
• For WSL users: update WSL using the official update commands / mechanisms the product exposes (this will vary between Windows versions and WSL distributions); Microsoft typically pushes kernel updates via the WSL update mechanism for WSL2 when needed.
• Where patching the kernel immediately is not feasible, restrict local users’ ability to mount untrusted block devices or images (apply stricter mount policies, limit CAP_SYS_ADMIN to trusted processes, restrict VM access to attach arbitrary volumes).
• For multi-tenant or shared systems: disallow attachment of arbitrary HFS+ images or scans from untrusted tenants.

These are pragmatic steps that reduce attack surface while you plan a kernel update.

---

Patching and long‑term remediationing kernels on Azure Linux instances using Microsoft’s recommended kernel updates and package repositories. Microsoft’s VEX and advisories are designed to point Azure customers to the vendor‑tested fixes.​

• For other Microsoft artifacts (WSL kernels, AKS images, Marketplace images), track vendor bulletins and ask for per‑artifact VEX/CSAF attestations if you need machine‑readable consoft hasn’t published an attestation, extract the kernel config from an exemplar instance and verify whether HFS+ is present and whether the kernel version includes the upstream fix.
• Where rebuilding a custom image, ensure the vulnerable upstream commits are picked up (or excluded) explicitly in your build pipelines, and keep kernel builds reproducible and traceable so you can always map a binary kernel to the upstream commits it contains.

---

Risk analysis — what makes this vulnerability important​

• The bug is a kernel memory access issue in a filesystem driver that can lead to crashes (denial of service) and — in some circumstances — limited information exposure depending on the memory read semantics. The Linux announce and exploitability notes show the KASAN trace for an out‑of‑bounds read that can crash the kernel during directory enumeration on an HFS+ volume. That gives the vulnerability an important severity profile.
• Exploitability in practice: exploitation requires an attacker to cause the target kernel to parse or enumerate an attacker‑controlled HFS+ filesystem. That means the most likely adversary models include any scenario where untrusted disk images or external HFS+ volumes can be attached and parsed by the target kernel — for example, attackers who can supply VM disks, mount network‑served HFS+ images, or trick administrators into mounting a crafted HFS+ device. The vulnerability is less likely to be exploitable remotely without such an attachment vector.
• Attack surface in Microsoft environments: Azure Linux VMs that allow customers to attach arbitrary disks, Marketplace images that permit image import, or WSL instances that foreign images — any of these could become a vector if they include the vulnerable driver and an attacker can present a crafted HFS+ filesystem. This is why, from a defender’s perspective, you must treat Microsoft’s Azure Linux attestation as helpful but not exhaustive for all Microsoft artifacts.

---

Strengths and limitations of Microsoft’s approach​

Strengthsn to publish CSAF/VEX attestations and begin with Azure Linux is a clear step toward machine‑readable, automatable vendor attestations for open‑source component coverage. That improves defenders’ ability to triage quickly when specific Microsoft product families are affected.

• Microsoft’s public wording and the VEX promise to update CVE entries if additional products are impacted adds transparency and commits the vendor to ongoing mapping activity.

Limitations / Risks:

• Product‑scoped attestations leave an operational gap unless the vendor attests all artifacts that ship their kernels. Until Microsoft (or any vendor) publishes per‑artifact attestations for WSL kernels, marketplace images, AKS node images, etc., operators cannot rely solely on the vendor VEX for full coverage. The onus remains on operators to either (a) obtain per‑artifact attestations, or (b) inspect kernels themselves.
• Machine‑readable attestations are only as useful as their coverage. Attestation programs are valuable, but defenders must treat them as a complement to SBOMs, per‑artifact inspections, and patch management processes — not a replacement.

ns for IT teams and operators

• Treat Microsoft’s Azure Linux VEX as authoritative for Azure Linux and apply Microsoft’s kernel updates on Azure Linux instances immediately. Use the VEX to automate triage for those images.
• For any other Microsoft artifact in your environment (WSL, AKS node pools, Marketplace images, internal images derived from Microsoft kernels):
• Require a per‑artifact CSAF/VEX from Microsoft, or
• Inspect the kernel config and confirm whether the HFS+ driver is present and whether your kernel version contains the upstream fix.
• If you discover the HFS+ driver is present and you cannot patch immediately, apply temporary mitigations (unload and blacklist the module, restrict mounts of untrusted images, and tighten CAP_SYS_ADMIN usage).
• Add checks into image‑validation pipelines to automatically grep kernel configs for risky drivers (CONFIG_HFSPLUS) before publishing images to production.
• For customers using WSL at scale in enterprise endpoints, talk to your endpoint security team about WSL kernel updates; ensure Windows update and WSL update mechanisms are applied and tested (and for managed environments, centrally track WSL kernel patching status).
• Subscribe to vendor VEX/CSAF feeds (Microsoft’s MSRC feeds) and upstream Linux kernel CVE announcements so you get automated signals for both attested product coverage and the upstream technical details.

---

Final assessment​

Microsoft’s public reply that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate and useful. It is anAzure Linux — and Microsoft has committed to producing machine‑readable VEX/CSAF attestations and to updating CVE mappings if they identify impact to additional Microsoft products. That means Azure Linux customers should act on the attestation now and apply vendor updates.
However, Azure Linux is not automatically the only Microsoft product that could include the vulnerable HFS+ driver. Any Microsoft artifact that ships a Linux kernel (WSL kernels, AKS node images, Marketplace images, or other kernel‑based appliances) can be a potential carrier if the HFS+ code was present in the build. Defenders must therefore combine Microsoft’s VEX signals with artifact‑level inspection (kernel config, module lists, or SBOMs) to be certain about exposure. Until Microsoft publishes per‑artifact attestations or you validate those artifacts yourself, treat them as unverified rather than definitively unaffected.
The operational takeaway for admins: act quickly on Azure Linux VEX guidance, and extend similar scrutiny to other Microsoft‑supplied artifacts in your environment. Use short‑term mitigations (module unload/blacklist, mount restrictions) where patching is delayed, and tighten processes to require per‑artifact attestations or reproducible kernel provenance for any production image that you rely upon.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center