CVE-2025-38635: Azure Linux Patch for DaVinci Clock Driver

A null-pointer robustness fix in the Linux kernel’s DaVinci clock driver — tracked as CVE‑2025‑38635 — has been published and patched upstream; Microsoft’s public advisory confirms Azure Linux as a confirmed carrier but does not, and cannot, by that statement alone guarantee that no other Microsoft-distributed Linux artifacts contain the same vulnerable code. The practical consequence for administrators and security teams is simple and urgent: treat Azure Linux images as in‑scope, verify other Microsoft Linux artifacts in your estate, and apply patched kernels where they appear.

Background / Overview​

The issue is a classic robustness bug: devm_kasprintf can return NULL on allocation failure, and the function davinci_lpsc_clk_register in the drivers/clk/davinci code path did not check that return value. The missing check could lead to a NULL pointer dereference when the kernel later dereferences the returned pointer. The upstream remedy was a small defensive patch that checks the devm_kasprintf return, cleans up already‑allocated resources, and returns an error pointer instead of allowing a crash.
This is a kernel‑level availability bug: the vulnerability’s impact is primarily denial-of-service (a kernel crash) rather than data exfiltration or privilege escalation. The Linux kernel tree accepted a fix, and stable branches have received backports. Multiple vendor security trackers and distribution advisories have recorded the CVE and indicate that the fix has been included in distribution kernel updates.
Why this matters for Microsoft customers: Microsoft has publicly stated that Azure Linux includes the open‑source code implicated by the CVE and therefore Azure Linux images are confirmed as potentially affected until they are updated. Microsoft’s published wording is an attestation for the Azure Linux artifact set — it is not a blanket assertion that other Microsoft products are free of the code. Microsoft has also explained that their CSAF/VEX rollout started with Azure Linux, and they will update CVE records and attestations as inventories for other product families are completed.

---

What CVE‑2025‑38635 actually is (technical summary)​

• Vulnerable component: Linux kernel driver code under drivers/clk/davinci (function davinci_lpsc_clk_register.
• Root cause: Missing NULL check after devm_kasprintf — allocation failure can return NULL and subsequent dereference causes a kernel NULL pointer dereference.
• Effect: Kernel NULL pointer dereference leading to a crash (availability impact).
• Attack context: Local code path inside the kernel; exploitability requires the attacker to be able to trigger the code path (local/privileged or via device interactions on systems with the driver present).
• Mitigation: Upstream defensive check added; distributions have backported the fix into their kernel packages; apply vendor kernel updates and reboot.

The upstream fix is a straightforward defensive change: after devm_kasprintf the code now tests whether the returned pointer is NULL. On failure it unregisters any previously-registered clock hardware, frees allocated structures, and returns an error pointer indicating -ENOMEM. The patch was accepted into the kernel stable backport queues and distributed to downstream kernels.

---

Why Microsoft named Azure Linux, and what it does — and doesn’t — mean​

Microsoft’s MSRC (Security Update Guide) FAQ text that appears on many Linux‑related CVE pages repeats two linked points:

• Microsoft is attesting that Azure Linux (the Microsoft‑curated Linux distribution / cloud images and kernel builds) includes the upstream code implicated by the CVE and is therefore potentially affected.
• Microsoft has begun publishing CSAF/VEX attestations (machine‑readable inventory and impact information) and will expand the scope to additional product families as their internal inventory work completes.

Important nuance for operations and security teams:

• The MSRC statement is an authoritative attestation for Azure Linux. If you run Azure Linux images, you should treat those images as in‑scope and apply the updates Microsoft provides.
• The statement is not a technical proof that no other Microsoft artifact contains the vulnerable code. Microsoft ships and maintains multiple Linux artifacts across product families (for example, the WSL2 kernel Microsoft distributes with Windows, linux‑azure kernels used for some VM SKUs, CBL‑Mariner lineage artifacts used in certain services, Marketplace images, and container host images). Each artifact is a separately built kernel with its own configuration. Whether a particular artifact includes the davinci driver is a build‑time property — only inspection of that artifact (or an official attestation) will confirm presence or absence.

Put another way: Microsoft’s attestation confirms a hit (Azure Linux). It does not prove exclusivity.

---

Are other Microsoft products likely to include the vulnerable code?​

Short answer: technically possible but depends on artifact and build configuration.
Why: the DaVinci clock driver and related files live under an ARM‑oriented path (TI DaVinci platform support). These drivers are only built in kernels that include the DaVinci architecture/driver configuration flags. Typical cloud and desktop kernels built for x86_64 omit many SoC‑specific drivers that only make sense on embedded ARM boards. That means in practice:

• Many Microsoft kernel artifacts that target x86_64 server/cloud VMs or desktop use cases likely do not include the DaVinci driver.
• However, any Microsoft kernel artifact built for ARM targets (or built from a configuration that includes broad multi‑arch support) could include the driver.
• The only authoritative way to determine inclusion is to inspect the particular kernel artifact (running or packaged) or await Microsoft’s expanded VEX/CSAF mapping for other product families.

Concretely, plausible Microsoft artifacts to check (beyond Azure Linux):

• WSL2 kernel builds Microsoft ships with Windows (the WSL2 kernel source and config is public and is a Microsoft‑maintained kernel artifact).
• linux‑azure / kernel‑azure packages that Microsoft or cloud partners use for some VM types.
• CBL‑Mariner and other Microsoft Linux images used for container hosts, Azure appliance images, and some Marketplace images.
• Any platform‑specific kernel images used for ARM‑based cloud instances (if Microsoft offers ARM VM SKUs).

None of these is automatically excluded by the MSRC FAQ — they have to be validated per artifact.

---

How to verify whether your Microsoft‑branded Linux artifact contains the davinci driver (practical tests)​

The presence of the vuln boils down to whether the kernel build includes the drivers/clk/davinci code or a module derived from it. Use the following checks on a running system or on an image:
On a running VM or Linux instance (Azure VM, WSL, Marketplace image, AKS node):

• Determine kernel version and release:
• uname -a
• Inspect the kernel configuration (if /proc/config.gz is available):
• 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:
• grep -i davinci /boot/config-$(uname -r)
• Search modules for davinci strings:
• find /lib/modules/$(uname -r) -type f -name 'davinci' -print
• ls /lib/modules/$(uname -r) | grep -i davinci
• Check whether a module is currently loaded (less likely):
• lsmod | grep -i davinci
• modinfo davinci* (if modules exist and modinfo is available)
• Search the kernel dmesg or journal for davinci messages:
• dmesg | grep -i davinci

For WSL‑specific checks:

• WSL ships a Microsoft‑maintained Linux kernel that is updated via Windows Update or the WSL kernel MSI; you can either check the running kernel (uname -a, /proc/config.gz) or examine the Microsoft WSL kernel repository and the Microsoft/config‑wsl configuration file to see whether DAVINCI/architecture options are enabled in the released config for the specific WSL kernel tag you are running.

For offline images, container layers, or kernel packages:

• Unpack the image or package and list /lib/modules/<kernel-version> for davinci files.
• Inspect the packaged kernel config file (often installed under /boot).
• For container images, run:
• docker run --rm -it image grep -R --line-number -i davinci /lib/modules || true
• For RPM/DEB packages, query package contents:
• rpm -ql kernel-package | grep -i davinci
• dpkg -c kernel-image*.deb | grep -i davinci

If these checks find files or config flags that reference DaVinci, the artifact contains the code and should be patched.

---

Remediation and mitigation guidance (operational steps)​

• Prioritize Azure Linux images and instances: Microsoft has attested Azure Linux as a confirmed carrier. Apply Microsoft’s kernel/security updates for Azure Linux images and reboot instances per normal patching windows.
• Inventory other Microsoft Linux artifacts you run:
• WSL2 instances (check running kernels or the WSL kernel tag).
• Marketplace images and custom images derived from Microsoft artifacts.
• AKS node images or other managed node pools running Microsoft‑curated images.
• For each artifact, perform the verification steps above. If the davinci driver or relevant kernel version is present, apply the vendor/OS patch that includes the upstream fix or upgrade to a patched kernel release.
• For WSL2 on Windows clients:
• Ensure Windows Update and the WSL kernel package are current.
• Alternatively, if you run a custom WSL kernel, rebuild using a patched kernel tree that includes the upstream fix and replace the kernel binary used by your WSL configuration.
• If you cannot patch immediately:
• Isolate affected systems from untrusted local users.
• Reduce exposure to any local code execution paths that might trigger the driver (for example, restrict access to device nodes) — note that mitigations are limited because this is a kernel‑level robustness issue; patching and rebooting is the practical fix.
• For embedded or specialized ARM devices that must include DaVinci support:
• Contact your device vendor for their kernel security advisory and a patched firmware/kernel image.
• If you build kernels yourself, apply the upstream patch (check the commit applied in stable backports), rebuild with your device’s config, and deploy.

---

Detection, telemetry and monitoring recommendations​

• Add kernel crash (OOM or NULL deref) signatures to your monitoring playbooks. The bug manifests as kernel panic or oopses with stack traces that reference davinci_lpsc_clk_register or drivers/clk/davinci.
• Deploy automatic artifact checks in your CI/CD and image build pipelines:
• Inspect kernel packages and image layers for vulnerable kernel versions or the presence of drivers/paths mentioning “davinci”.
• For managed estates, use SBOM / VEX / CSAF feeds where available. Microsoft’s early CSAF/VEX rollout starts with Azure Linux — ensure your automated tooling consumes Microsoft VEX attestations when they are available.
• Where possible, enforce periodic config checks that confirm kernel config flags for each kernel build do not include unneeded SoC-specific drivers.

---

Risk analysis and context​

Strengths of the upstream fix and ecosystem response

• The upstream fix is small and localized — a simple defensive NULL check with proper cleanup. That makes it easy to backport and include in stable kernel releases.
• Kernel maintainers and major distributions have treated this as a moderate availability bug and have included backports in distribution kernel updates. Public trackers show fixed package versions across multiple distributions.
• The attack surface is limited: this is not a remote RCE; it requires the vulnerable driver to be present and a path to trigger the code path (often a local operation or device interaction). That reduces the exploitation surface compared to remote memory‑corruption vulnerabilities that enable arbitrary code execution.

Practical risks that still matter

• Availability impact in multi‑tenant or automated environments: an attacker who can trigger a kernel crash on a shared host (or on a critical system) can cause disruption at scale. In cloud environments this is operationally significant.
• Inventory blind spots: large vendors ship many artifacts. Microsoft’s Azure Linux attestation is useful and authoritative for that product family, but absence of attestations for other Microsoft artifacts is not evidence of absence. Administrators who assume "only Azure Linux is affected" risk missing vulnerable kernels in other artifacts.
• Embedded/ARM deployments: the driver is SoC‑specific; embedded or ARM‑targeted devices that include DaVinci drivers are the highest realistic exposure for this particular piece of code. Those devices are often on longer patch cycles and may be harder to update.

---

Action checklist (short, executable)​

• If you run Azure Linux images: patch to the updated Azure Linux kernel package and reboot immediately.
• Inventory other Microsoft kernel artifacts you run (WSL2, linux‑azure kernels, Marketplace images, AKS nodes). Use the verification steps above.
• If your artifact contains the davinci code: apply the appropriate vendor or distribution patch, or rebuild your kernel including the upstream fix, and schedule a reboot.
• Add detection rules to log watchers for kernel oops/panic output referencing davinci_lpsc_clk_register or drivers/clk/davinci.
• Subscribe to vendor VEX/CSAF attestations and incorporate them in your SBOM/patch automation flow.

---

Closing analysis — what Microsoft’s wording actually signals​

Microsoft’s public advisory phrasing should be read as a precise product attestation, not a global guarantee. The practical upshot for defenders:

• Treat Azure Linux as a confirmed affected artifact and remediate accordingly.
• Don’t assume other Microsoft kernels are safe purely because Microsoft’s release page doesn’t list them — the attestation program is phased and artifact‑scoped.
• Verify other Microsoft‑distributed Linux artifacts yourself: WSL2 kernels, linux‑azure builds, Marketplace images, and CBL‑Mariner derived images are all plausible places where upstream kernel code might be present depending on build configuration.

The good news is that the technical fix is small and available upstream and in distribution patches; the operational task is inventory + patching. Prioritize Azure Linux immediately, then verify and patch other Microsoft Linux artifacts in your environment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center