Azure Linux ksmbd CVE-2025 38575: What MSRC Attestation Means

Microsoft’s short MSRC advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate as a product attestation, but it is not a categorical statement that no other Microsoft product can contain the same vulnerable ksmbd code; Azure Linux is the only Microsoft product Microsoft has publicly attested as including the affected component for CVE‑2025‑38575 so far, and Microsoft has pledged to update that mapping if additional Microsoft products are identified.

---

Background / Overview​

CVE‑2025‑38575 is a Linux kernel vulnerability in the ksmbd subsystem (the in‑kernel SMB server implementation) that was fixed upstream by replacing an unconditional free with the correct aead helper that zeroes sensitive cryptographic memory before release. The underlying bug is a straightforward memory‑management mistake: code freed a buffer allocated by aead_request_alloc() using kfree() instead of calling aead_request_free(), leaving a window in which secret material might remain in memory after the buffer was released. The upstream patch and the public CVE metadata document this single-line corrective change.
Why this matters: ksmbd handles SMB protocol operations inside the kernel and will, depending on build/configuration and runtime usage, process cryptographic material. Even when a particular bug is technically limited in exploitability, the presence of residual secret data in freed pages is a reliability and confidentiality concern; secure crypto helpers exist precisely to ensure zeroization semantics. Multiple distributors and vulnerability databases tracked CVE‑2025‑38575 and published advisories and fixes as Linux kernel updates in April–May 2025.

---

What Microsoft actually said — and why that wording is precise​

Microsoft’s MSRC entry for the CVE contains a short FAQ answer that reads in effect: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” That sentence is an inventory attestation — Microsoft has inspected the Azure Linux product (its kernel packages and images) and found the upstream ksmbd code that maps to this CVE, and therefore Azure Linux images are in scope for remediation and patching. Microsoft also stated that it began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update CVE records if it identifies impact to additional products.
Two separate but crucial implications follow from this wording:

• It is an authoritative, product‑level confirmation for Azure Linux — if you run Azure Linux images, treat them as potentially affected and follow Microsoft’s remediation guidance.
• It is not an exclusivity claim — absence of a similar public attestation for another Microsoft product is not proof that the product is free of the vulnerable code. Microsoft’s VEX/CSAF rollout is phased and product‑by‑product, so many Microsoft artifacts remain un‑attested until inventory work is finished.

Security teams should treat the MSRC line as an operational priority signal (patch Azure Linux first if you run it) and not as a blanket statement about every Microsoft image or binary.

---

Technical anatomy of CVE‑2025‑38575 (what was wrong, exactly)​

The change that resolves CVE‑2025‑38575 is small and surgical: replace a call to kfree(req) with aead_request_free(req) in fs/smb/server/auth.c inside the ksmbd code path. The reason is not stylistic — aead_request_free() guarantees that the memory allocated by aead_request_alloc() is zeroed before it is freed, which prevents leftover key material, nonces, or other secret buffers from surviving after deallocation. The patch was submitted and merged into the stable trees in March–April 2025.
Key technical points:

• The bug is a memory zeroization defect rather than a classic remote code‑execution primitive. That typically reduces immediate exploitability but raises confidentiality risk where kernel‑side cryptographic buffers are used.
• The fix is present in the upstream kernel stable trees; distributors applied the patch in their kernel updates and security errata. Check your distribution’s kernel advisory list for the exact package names and CVE mapping.

---

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

Short answer: No — not necessarily. Microsoft has publicly attested only Azure Linux as including the affected ksmbd code for CVE‑2025‑38575, but other Microsoft artifacts that ship or run Linux kernels could also contain the vulnerable code depending on kernel version and build configuration. The attestation is authoritative for the product named but not an exhaustive inventory of Microsoft’s entire artifact catalogue.
Why Microsoft’s single‑lind as exclusivity:

• Microsoft publishes VEX/CSAF attestations product by product; the presence of Azure Linux in the MSRC mapping reflects the inventory work completed to date, not a pledge that the rest of Microsoft’s product portfolio is clean. The company explicitly pledges to update the CVE if further impact is found.
• Whether a given Microsoft kernel artifact includes ksmbd is a build‑time decision. A kernel config may enable ksmbd as a module or built‑in, or omit it entirely. Two kernels built from the same upstream tree can differ in enabled features. That makes artifact‑level verification essential.
• Microsoft ships multiple Linux‑adjacent artifacts: WSL2 kernels, linux‑azure kernels for VM SKUs, OS images used in AKS node pools, curated Marketplace images, and management or telemetry images. Any of those could include ksmbd if the kernel configuration or packaging includes it — until Microsoft inventoriise.

So, the correct operational posture is: treat Azure Linux as an attested carrier (patch it), but do not assume other Microsoft products are ruled out unlished a Not Affected attestation or you have independently verified the absence of ksmbd.

---

Which Microsoft artifacts are plausible carriers? (what to check)​

While only Azure Linux is attested today, these Microsoft artifacts are logical places where the samppear:

• WSL2 kernel binaries that Microsoft builds and distributes. The WSL2 kernel is a Microsoft‑maintained kernel tree and the presence of ksmbd depends on the chosen kernel config. Inspect the WSL2 kernel config or the binary to confirm.
• *Azure VM images and linux‑azure kernelsnel builds for some VM families; those kernels may include ksmbd depending on build options.
• AKS node images and curated Marketplace images that use Microsoft‑maintained kernels or images. Some Marketplace images are maintained by Microsoft; others are third‑party. An Azure Linux VEX attestation does not automatically cover all Marketplace images.
• Container base images and Marketplace containers published by Microsoft. Containers may embed kernel modules only in init or sidecar images, but images used for development or appliance builds can carry vulnerable components in userspace or in their supplied runtime kernel references.

Each artifact is a discrete target for inventory/verification. The burden is on operators to scan the artifacts running in their estate and on Microsoft to expand attestations.

---

How to verify whether a given Microsoft artifact includes ksmbd​

You cannot rely on a single expectation — you must inspect the artifact. Practical verification approaches:

• Check kernel config for ksmbd options. Look for CONFIG_KSMBD and related flags in /boot/config-$(uname -r) or by extracting config from the image:
• grep -E 'KSMBD|CONFIG_KSMBD' /boot/config-*
• For WSL or packaged kernels, inspect the published kernel config accompanying the binary.
• Inspect the running kernel for ksmbd module presence:
• lsmod | grep ksmbd
• zgrep KSMBD /proc/config.gz (where /proc/config.gz exists)
• Search images and containers for kernel modules or for the presence of the fs/smb/server/auth.c artifact in build trees — this is easier on build artifacts or source trees than on compiled binaries. 4. Use automated SBOM/dependency scanning and binary analysis tools to identify which kernel versions and patches were used to build the image; compare commit hashes against the upstream fixes referenced by OSV/NVD.

If you do not find either a kernel config enabling ksmbd or any ksmbd module in the artifact, that specific artifact is unlikely to be affected — but verify for each artifact independently.

---

Immediate mitigation and patching guidance (for administrators and ISVs)​

If you operate Azure Linux images: prioritize the official kernel updates Microsoft publishes for Azure Linux and apply the vendor kernel errata as soon as practicable. Microsoft’s attestation makes Azure Linux the highest‑priority Microsoft product for immediate patching in this case.
For other Microsoft artifacts, and for mixed environments, follow this prioritized sequence:

• Inventory (fast, immediate)
• Use image scanning, SBOM records, and configuration management to list all Linux images, VMs, containers, and WSL kernels in your environment. Look for kernel families and versions that predate the upstream ksmbd fix.
• Verify (artifact‑level)
• For each artifact identified in step 1, check kernel config and module lists for ksmbd; where config is unavailable, check whether the kernel version and commit range include the upstream fix referenced by OSV/NVD.
• Patch and rebuild (remediation)
• Apply distribution kernel updates (Ubuntu USNs, Debian DLAs, vendor errata) that include the ksmbd fix; where you build images, rebuild with an updated kernel or updated module tree and redeploy.
• Reassess exposure and rotate secrets if necessary (defense‑in‑depth)
• If you find evidence that secret material could have been exposed (rare for this class of bug but possible in certain threat models), follow your incident response playbook: collect forensic artifacts, rotate keys and credentials, and escalate. Flag this as part of a broader audit process rather than a default step for all organizations.
• Monitor vendor attestations and automation (ongoing)
• Subscribe to MSRC VEX/CSAF feeds, distribution security advisories, and your own CI/CD SBOM automation. Microsoft has committed to publishing CSAF/VEX product mappings and to update CVE pages when additional impacted products are discovered, so incorporate those signals into your patching pipeline.

---

Detection: what a defender should look for​

• Unusual calls or crashes in ksmbd paths in kernel logs (dmesg) after patch deployment; look for correlated OOPS or stack traces referencing fs/smb/server or ksmbd_* symbols.
• Forensic memory analysis where possible: tools that can scan freed pages for residual key material are specialized and rarely part of standard IR toolkits; only escalate to this when you have reason to suspect key leakage.
• Inventory drift: many exposures occur not because of a single CVE but because of unmanaged or forgotten marketplace images or developer VMs; use SBOM and image scanning to reduce blind spots.

---

Practical examples — verification commands (operational playbook)​

• Check a running system:
• uname -a (identify kernel version)
• grep -i ksmbd /proc/modules || lsmod | grep ksmbd
• zgrep CONFIG_KSMBD /proc/config.gz || grep ot/config-*
• Scan an image offline (example): extract boot files from an Azure VM image or container and inspect /boot/config‑* for CONFIG_KSMBD, or examine the kernel package changelog for CVE references.

Note: these commands are illustrative — adapt them to your tooling and environment.

---

Risk assessment — strengths, limitations, and the realistic threat model​

Strengths of Microsoft’s approach:

• Microsoft’s product‑level attestation for Azure Linux is actionable — it allows Azure customers to triage and patch a known carrier quickly rather than guessing which Azure artifacts are affected. The commitment to publish VEX/CSAF is a forward step for machine‑readable vendor transparency and automatable patch management.

Limitations and residual risk:

• A product‑scoped attestation is not a global safety guarantee. Large vendors ship many distinct artifacts; identical upstream code can appear in multiple places by reuse, rebuilds, or packaging choices. Until a vendor publishes attestations for each artifact class (WSL, Marketplace images, container images, specialized kernels), defenders must assume un‑attested artifacts are unverified rather than “not affected.”
• The vulnerability itself is a zeroization issue — not an immediate remote code execution vector in most cases — so the urgency is medium for most operators, but it matters when replication of secret material or high‑privilege key handling occurs in kernel SMB code paths. National regulators and compliance programs may consider any cryptographic handling vulnerability higher priority due to data‑privacy implications.

Operational recommendation: treat Azure Linux as a confirmed in‑scope product and patch it promptly; run a short, focused inventory across all Microsoft artifacts you run and verify their kernel configs or update status. That combination addresses the immediate risk and the larger supply‑chain uncertainty.

---

What we could not independently verify (caveats)​

• Microsoft’s internal product inventory beyond Azure Linux: we cannot independently confirm whether Microsoft has already found this ksmbd code in other internal products or images that are not yet published in MSRC VEX attestations. Microsoft’s public promise is to update the CVE if additional products are discovered; until then, the public mapping names Azure Linux only. Treat this lack of public attestation as an evidence gap, not as evidence of absence.
• The practical exploitability in the wild: as of the upstream patch, public trackers do not report active exploitation campaigns specifically for CVE‑2025‑38575; the bug’s nature also makes large‑scale remote exploitation less likely than classic memory‑corruption bugs. However, every kernel vulnerability demands attention because kernels run at the highest privilege levels, and even limited confidentiality leaks can be relevant in high‑value environments. See NVD/OSV/Ubuntu advisories for distribution‑specific impact and patch availability.

---

Conclusion — clear steps for Microsoft customers and administrators​

• If you run Azure Linux: treat the MSRC attestation as an authoritative call to action — apply Microsoft’s Azure Linux kernel updates as soon as they’re available.
• If you run other Microsoft artifacts (WSL, AKS, Azure VM images, Marketplace images, or Microsoft‑published containers): do not assume your artifact is safe. Inventory and verify each artifact for ksmbd presence (CONFIG_KSMBD, modules, kernel version and commit hashes) and apply vendor updates or rebuilds where applicable.
• Automate discovery and SBOM generation across CI/CD and image pipelines so future product‑scoped attestations (CSAF/VEX) can be consumed automatically and remediation prioritized. Microsoft’s move to publish CSAF/VEX makes automation possible; incorporate those feeds into your patch orchestration when available.

In short: Azure Linux is the one Microsoft product Microsoft has publicly attested as including the vulnerable ksmbd code for CVE‑2025‑38575, and that attestation is authoritative for Azure Linux images. But that statement does not mean Azure Linux is the only possible Microsoft carrier of the same upstream code; operators must verify other Microsoft artifacts individually and follow the inventory → verify → patch lifecycle to reduce exposure across the estate.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center