Microsoft has publicly confirmed that Azure Linux is affected by a kernel vulnerability that could expose cryptographic secrets, but the careful wording of its advisory leaves security teams with more work than just applying a patch. The bug, tracked as CVE-2025-38575, resides in ksmbd—the in-kernel SMB server—and stems from a memory-management mistake that skips zeroing sensitive data before freeing it. While the official notice names Azure Linux, other Microsoft products that ship Linux kernels might also carry the vulnerable code without yet being flagged. If you run Azure Linux, patch now. If you run anything else with a Linux kernel from Microsoft, verify whether you’re exposed before assuming you’re in the clear.

What’s the vulnerability exactly?

The flaw lives deep inside the Linux kernel’s SMB server implementation. When the ksmbd code path processes cryptographic operations, it allocates a buffer with aeadrequestalloc() but incorrectly frees it with a plain kfree() instead of aeadrequestfree(). That single-line mistake, patched upstream in March–April 2025, leaves an opening where key material, nonces, or other secret buffers can linger in memory after deallocation. In practical terms, an attacker who gains read access to freed kernel pages—through another exploit, a misconfiguration, or a side-channel—might recover fragments of cryptographic keys.

This isn’t a remote code execution bug; it’s a confidentiality defect. But for systems handling high-value secrets, any leak at the kernel level is serious. The fix, replacing kfree(req) with aeadrequestfree(req), ensures the memory is zeroed before release, closing the window entirely. Stable kernel trees have already absorbed the correction, and most Linux distributions issued updates by early May 2025.

Who needs to worry—and why it’s not just Azure Linux

Microsoft’s MSRC advisory states: “Azure Linux includes this open-source library and is therefore potentially affected by this vulnerability.” The sentence is precise. It’s an authoritative attestation that Azure Linux images contain the vulnerable ksmbd code and must be patched. But the advisory does not claim that Azure Linux is the only affected Microsoft product. In fact, Microsoft has pledged to update the CVE record if additional product impact is uncovered, acknowledging that the phased rollout of machine-readable CSAF/VEX attestations means many artifacts still lack a formal status.

That distinction matters. Microsoft ships Linux kernels in several forms beyond the Azure Linux distribution itself: the WSL2 kernel, the linux-azure kernel used by some Azure VM families, AKS node images, and various Marketplace images that bundle Microsoft-maintained kernels. Whether any particular artifact includes ksmbd depends on how the kernel was configured at build time—a kernel config may enable the module, build it in, or omit it entirely. Two kernels built from the same source tree can differ. Without a specific “Not Affected” attestation from Microsoft for each artifact, administrators cannot assume safety.

So the immediate takeaway is twofold. First, if you operate Azure Linux, treat the advisory as a clear signal to patch immediately. Second, if you run any other Microsoft artifact that boots a Linux kernel—WSL2 instances, custom Azure VMs, AKS worker nodes, developer images—you must independently verify whether ksmbd is present and, if so, whether it’s been fixed.

How did we get here?

The ksmbd subsystem was merged into the Linux kernel in 2021 as a lightweight alternative to Samba for embedded and virtualized environments. It’s not enabled by default in all distributions, but it appears in many cloud-optimized kernels because it can accelerate SMB file sharing without userspace overhead. The zeroization bug was introduced during a routine refactoring, and the upstream fix was committed quietly as part of routine maintenance. Distributions then pulled the patch into their security errata.

Microsoft’s involvement is a direct consequence of its growing Linux footprint. Azure Linux is itself a curated distribution used inside Azure for cloud-native workloads. In October 2025, Microsoft began publishing CSAF/VEX security advisories in machine-readable formats—part of a broader push toward supply-chain transparency. The advisory for CVE-2025-38575 is one of the first tests of that system, and the wording reveals Microsoft is still working through its internal inventory of where the vulnerable code might reside.

What to do now: A practical checklist

For Azure Linux users, the path is straightforward: apply the official kernel update from Microsoft as soon as possible. For everyone else, follow a three-step inventory-verify-patch cycle.

1. Inventory your Linux-based Microsoft artifacts
List every image, VM, container host, and WSL environment that relies on a Microsoft-provided kernel. Pay special attention to:

  • WSL2 kernels (Microsoft builds and distributes these alongside Windows)
  • Azure VMs using the linux-azure or custom Microsoft kernel images
  • AKS node pools based on Microsoft-maintained images
  • Marketplace images labeled as “published by Microsoft” that include a Linux kernel
  • Any container images or development environments that embed or side-load kernel modules

2. Verify the presence of ksmbd
For each artifact, check whether ksmbd is enabled and, if so, whether the fix has been applied.

Run these commands on a live system:

# Check kernel version
uname -a

Look for the ksmbd module in the running kernel

lsmod | grep ksmbd grep -i ksmbd /proc/modules zgrep CONFIGKSMBD /proc/config.gz 2>/dev/null || grep -i ksmbd /boot/config-*

For images you can’t boot, extract the kernel config or the kernel package’s changelog and search for CVE-2025-38575 references. Many image-scanning tools can examine kernel binaries or config files offline. If you find CONFIGKSMBD=m or CONFIG_KSMBD=y in the configuration, the artifact is potentially affected. If the kernel version predates the upstream fix (commit range around March 2025), it likely needs updating.

3. Patch or rebuild

  • For distributions with official packages (Ubuntu, Debian, Fedora, etc.), apply the errata that address CVE-2025-38575. Check your distributor’s advisory for exact package names.
  • For Microsoft-provided artifacts like WSL2, watch for updated kernel releases from Microsoft. A new WSL2 kernel package will usually arrive through Windows Update or winget.
  • If you build custom images from a Microsoft kernel tree, pull the latest commits and rebuild.

4. Defense-in-depth measures
Given the nature of the bug, consider rotating any cryptographic keys that might have been handled by the kernel’s SMB server if your threat model warrants it. This is a precaution—there are no publicly reported active exploits—but it aligns with a robust incident response plan for confidentiality flaws in privileged code.

The bigger picture: Why this bug matters even without active exploits

On its own, CVE-2025-38575 is not a headline-grabbing remote code execution vulnerability. But for organizations handling regulated data or running multi-tenant environments, any uncontrolled leakage of secret material from kernel memory can trigger compliance obligations. Data privacy regulations increasingly require that cryptographic keys and sensitive parameters be scrubbed from memory immediately after use. A bug that skips that step undermines defense-in-depth, especially if combined with a separate information-disclosure flaw.

The risk is also cumulative. Every kernel vulnerability that leaves secret data in freed pages adds to the noise floor an attacker must wade through, but for targeted attacks, even residual fragments can be valuable. Treating this as a mandatory patch cycle—even for non-Azure-Linux artifacts—closes a small but measurable gap.

What’s next

Microsoft has committed to updating the CVE page if it finds the vulnerable code in additional products. The move to CSAF/VEX is expected to accelerate that process, but the timeline is unknown. For now, the safest posture is to assume any Microsoft-provided Linux kernel that hasn’t been explicitly marked “Not Affected” could contain the bug—and to verify for yourself.

Longer term, this incident underscores the need for systematic SBOM generation and continuous image scanning. When a vendor says “this product is affected,” that statement should automatically trigger patching workflows for that product. When a vendor says nothing about another product, your own tooling should flag the absence of an attestation as a risk until proven otherwise. CVE-2025-38575 is a small bug in a small kernel subsystem, but it’s a valuable reminder that product-level advisories don’t draw a perimeter around risk—they just illuminate the parts the vendor has checked.