Microsoft has publicly confirmed that Azure Linux carries a kernel-level flaw that can be exploited to crash affected systems. The vulnerability, tracked as CVE-2025-38635, stems from a missing pointer check in an obscure but important driver, and while Microsoft has already shipped a fix for Azure Linux, the way it worded its advisory signals that other Microsoft-distributed Linux kernels might also be at risk—and that it's on administrators to find out.

The bug itself isn't a remote code execution nightmare. It's a local availability problem: a null-pointer dereference in the DaVinci clock driver that can panic the kernel and force a reboot. For cloud workloads and critical infrastructure, hard crashes are more than an inconvenience—they mean downtime, ticket storms, and, in multi-tenant environments, potential disruption of multiple services if a shared host goes down. The fix is a small, defensive change already backported into stable kernel trees, but the real story is about the gaps in Microsoft's disclosure and the practical steps defenders must take right now.

What changed

The heart of the issue sits in the Linux kernel's DaVinci clock driver, specifically in the function davinci_lpsc_clk_register under drivers/clk/davinci. That function uses devm_kasprintf to allocate a string, but it never checked whether the allocation succeeded. If memory is tight, devm_kasprintf returns NULL, and a later dereference of that pointer triggers a classic kernel oops—the system freezes or reboots.

Upstream maintainers accepted a patch that adds a simple NULL test after the allocation. On failure, the code now unregisters any already-registered clocks, frees allocated memory, and returns an error pointer, cleanly aborting the operation. The fix landed in the mainline kernel and was quickly backported to long-term stable branches. Major distributions incorporated it into their update streams, and Microsoft's advisory is part of that broader ecosystem response.

The advisory itself is notable for what it says and what it doesn't say. Microsoft's Security Response Center (MSRC) writes on the CVE-2025-38635 page that Azure Linux includes the open-source code in question and is therefore potentially affected. It also notes that the company began publishing Common Security Advisory Framework (CSAF) and Vulnerability Exploitability eXchange (VEX) attestations in October 2025, starting with Azure Linux, and that additional product families will be covered as internal inventories are completed. That carefully scoped language is the kernel of the concern: it attests to Azure Linux, but it does not reach out and declare other Microsoft Linux artifacts safe.

Who's at risk—and what's really at stake

For anyone running Azure Linux images, the message is clear: you are affected until you patch. Microsoft has confirmed it, and the updated packages are already available. The operational impact is a denial-of-service: an attacker who can trigger the vulnerable code path—which usually requires local access or a specially crafted interaction with a device node—can crash the kernel. In a shared cloud setting or a Kubernetes cluster, a deliberate crash could knock out nodes, forcing rescheduling and potentially opening a window for other mischief.

If you manage an Azure Linux deployment, treat this as a priority patch cycle. The fix is out; applying it and rebooting is straightforward.

The ambiguity grows when you look beyond Azure Linux. Microsoft ships and maintains Linux kernels in multiple guises:

  • WSL2 kernels that accompany Windows and are updated via Windows Update or a standalone MSI.
  • linux-azure packages used for certain VM SKUs.
  • CBL-Mariner-based images that run container hosts, AKS nodes, and various Azure appliances.
  • ARM-based cloud instance kernels, if Microsoft offers those.

Each of these artifacts is built from a different kernel configuration. The DaVinci driver targets Texas Instruments SoCs—it's an ARM-oriented piece of code. Typical x86_64 kernels don't enable DaVinci support, so many cloud and desktop builds are likely clean. But if a kernel is built with broad multi-architecture support, or if it's an ARM build, the driver could be compiled in. The only way to be certain is to check the specific artifact.

Put bluntly: Microsoft's advisory does not assert that Azure Linux is the only affected product. It says Azure Linux is confirmed, and that other products will be assessed later. Until then, the other artifacts are an inventory blind spot. Administrators who assume they're safe just because the advisory page doesn't list WSL2 or a Marketplace image could be in for a nasty surprise.

A timeline of the issue

The upstream kernel patch went through the normal process. The missing NULL check was identified as a robustness weakness, a fix was developed, and stable kernels picked it up. Microsoft's MSRC, as part of its newer transparency push around Linux security, mapped the CVE to Azure Linux and published the advisory we see today. The timing is notable because it coincides with Microsoft's CSAF/VEX rollout—an effort to give customers machine-readable security data. That rollout is phased, and Azure Linux is the first product family covered. Other product families are slated to follow, but no date is given. So the patch has been available for weeks or months in the kernel trees, but the advisory just now appears from Microsoft, with its specific Azure Linux focus.

What to do now

If you run Azure Linux, the path is short: apply Microsoft's latest kernel update and reboot. Use your normal patch management workflow. No other mitigation is needed once the new kernel is in place.

For every other Microsoft Linux artifact in your estate, you need a quick verification routine. The goal: check whether the running kernel includes the DaVinci clock driver. Here are the steps that work on most live systems.

First, find your kernel version with uname -a. Then check the kernel configuration. If /proc/config.gz is available, run:

zcat /proc/config.gz | grep -i DAVINCI
zcat /proc/config.gz | grep -i CLK_DAVINCI
zcat /proc/config.gz | grep -i ARCH_DAVINCI

If /boot/config-$(uname -r) exists, use grep -i davinci /boot/config-$(uname -r).

Look for lines like CONFIG_COMMON_CLK_DAVINCI=y or CONFIG_ARCH_DAVINCI=y. Any hit means the driver is compiled in. If you see =y, it's built statically; =m means it's available as a loadable module.

Even if the config doesn't flag it, verify the modules directory:

find /lib/modules/$(uname -r) -type f -name 'davinci*'
ls /lib/modules/$(uname -r) | grep -i davinci

If a file shows up, the driver can be loaded. Also check if it's currently active with lsmod | grep -i davinci and dmesg | grep -i davinci.

For WSL2 specifically, you have two angles. If you use the Microsoft-provided WSL kernel, ensure Windows Update has delivered the latest version. You can check the kernel release with uname -r and compare it to the published WSL kernel MSI notes. If you build a custom WSL kernel, you must rebuild it from a source tree that includes the upstream commit that fixes CVE-2025-38635. Microsoft's WSL kernel GitHub repository shows the config used; inspect it for DaVinci flags.

For offline images or container layers, unpack and inspect. For RPM-based systems, rpm -ql kernel-package | grep -i davinci can reveal driver files. For Debian-based, dpkg -c kernel-image*.deb | grep -i davinci. For Docker images, a quick run can do the trick:

docker run --rm -it <image> bash -c "find /lib/modules -name '*davinci*' 2>/dev/null; grep -r davinci /boot 2>/dev/null"

If any verification finds a match, you have a vulnerable kernel. The remedy is vendor-provided updates. For first-party Microsoft artifacts like Azure-tuned kernels or WSL2 kernels, apply the latest package from Microsoft. For others, check your Linux distribution's update channels. The upstream fix is present in stable kernels released after the patch was merged; updating to the latest stable kernel for your distribution is the safest route.

After patching, reboot to ensure the new kernel is running.

While patching, add detection rules to your monitoring. Kernel oops or panic messages that mention davinci_lpsc_clk_register or drivers/clk/davinci are a smoking gun for this CVE. Having alerts on those strings can help you spot an exploitation attempt or an unpatched system that crashes.

Outlook

Microsoft's phased CSAF/VEX rollout means this won't be the last advisory of its kind. Products like WSL2, linux-azure, and CBL-Mariner will eventually get their own attestations—and until they do, the burden of verification falls on administrators. This CVE is a good test case: the technical fix is trivial, but the disclosure gap forces a manual, artifact-by-artifact inventory.

Beyond this single bug, the lesson is clear: when a vendor attests a specific product family as affected, don't treat every other product from that vendor as implicitly safe. Especially with Linux components shared across multiple packages, code reuse can silently spread vulnerabilities. Regular kernel configuration audits, combined with SBOM and VEX consumption, are becoming a baseline requirement. Use this opportunity to tighten those processes, and keep an eye on the MSRC updates for expanded product coverage.