Microsoft has confirmed that a Linux kernel NULL pointer dereference in the Raspberry Pi clock driver can crash systems running Azure Linux, and while the company has issued a patch, it warns that other Linux images it ships may also contain the vulnerable code—and it hasn’t finished checking them all yet.
What Actually Changed
The core of CVE-2025-38160 is a missing NULL check after a call to devm_kasprintf() inside the raspberrypi_clk_register() function, located in drivers/clk/bcm/clk-raspberrypi.c. When memory allocation fails, the function returns a NULL pointer, and the code proceeds to dereference it without any guard. That triggers a kernel oops or outright panic, taking the system down. The upstream Linux fix is surgical: immediately after the allocation, a check for NULL is added, and if the allocation failed, the function returns an error safely.
According to the Linux CVE announcement, stable kernel trees have backported the fix to multiple branches. Microsoft’s advisory for this vulnerability states clearly that Azure Linux “includes this open‑source library and is therefore potentially affected.” That attestation is authoritative—if you use Azure Linux, you must act. But the advisory also carries a crucial caveat: Microsoft will update the CVE if it identifies impact to additional products. In plain terms, the company has only completed its vulnerability inventory for Azure Linux so far; other Microsoft Linux artifacts remain unchecked.
What It Means for You
For Azure Linux administrators: This is a high-priority patch. An unprivileged local user, a misbehaving container, or a service that interacts with the clock driver could trigger a crash and cause an availability loss. Microsoft has released an updated image or kernel package for Azure Linux. Apply it immediately across all your VMs and container hosts.
For users of other Microsoft Linux images: The advisory does not yet cover the linux-azure kernel used in some VM SKUs, Azure Kubernetes Service (AKS) node images, Azure Marketplace images, or the Windows Subsystem for Linux 2 (WSL2) kernel. Any of these could be built from a kernel tree that includes the vulnerable driver. Until Microsoft publishes an attestation for each product, you should treat them as potentially affected and verify for yourself.
If you manage Raspberry Pi devices in production: The bug is in the Broadcom BCM clock driver specific to Raspberry Pi hardware. If you run a stock Raspberry Pi OS or a custom kernel on those boards, you need the upstream kernel fix—the patch isn’t exclusive to Azure Linux.
How We Got Here
NULL pointer dereferences are among the most common kernel bugs, often introduced by missing error handling after memory allocations. The devm_ helper functions are designed to simplify resource management, but they return NULL on failure, and developers sometimes forget to check. In this case, the oversight persisted in the Raspberry Pi clock driver until upstream maintainers caught it and added the guard.
Microsoft’s involvement comes from its growing use of Linux in Azure. Since October 2025, Microsoft has been publishing Common Security Advisory Framework (CSAF) documents and Vendor Exploitability eXchange (VEX) statements for open-source components it ships. Azure Linux was the first product to be systematically inventoried in this transparency push, which is why it’s the only one named in the advisory. Microsoft plans to expand attestations to other products, but for now, the gap means defenders can’t rely solely on Microsoft’s word for images beyond Azure Linux.
What to Do Now
1. Patch Azure Linux Immediately
If you have any Azure Linux VMs or containers, locate the patched image or kernel version listed in Microsoft’s advisory and deploy it across your fleet. Do not delay—an attacker or a simple memory pressure scenario can trigger the crash.
2. Inventory All Microsoft-Sourced Linux Images
Compile a list of every Linux image you run that came from Microsoft channels: AKS node images, Azure VM marketplace images, WSL2 kernels, custom images built from Azure base images, and any partner images distributed through Microsoft. For each, collect the kernel version and note whether the vulnerable driver might be present.
3. Scan for the Vulnerable Driver
On a running system, check if the driver module is loaded by running:
lsmod | grep clk_raspberrypi
Alternatively, look for the file drivers/clk/bcm/clk-raspberrypi.c in the kernel source tree. If the driver is compiled statically into the kernel, you’ll need to inspect the kernel configuration (look for CONFIG_ options related to the BCM clock driver).
4. Map Kernel Versions to the Upstream Fix
The upstream commit history shows the fix was backported to these stable releases:
| Stable Series | Fixed Release / Release Candidate |
|---|---|
| 5.10 | 5.10.227-rc1 |
| 5.15 | 5.15.166-rc1 |
| 6.1 | 6.1.105-rc1 |
| 6.6 | 6.6.46-rc1 |
| 6.10 | 6.10.5-rc1 |
| 6.11 | 6.11-rc3 |
If your kernel version is older than the fixed release in its branch, you’re vulnerable and need an update.
5. Update WSL2 Kernels Cautiously
The WSL2 kernel is a custom build distributed through Windows Update or as a downloadable MSI. Inside a WSL2 instance, run uname -r to check the kernel version. If it predates the fixed range for its base (typically a 5.15 or 6.1 LTS fork), download the latest WSL2 kernel from Microsoft’s GitHub releases and install it, or wait for the automatic update.
6. For Managed Services, Use Provider Guidance
If you use AKS or Azure VM Scale Sets, follow the official channels for node image upgrades. Microsoft typically rolls out patched images for managed services, but you may need to trigger a node pool upgrade. Check the release notes for your service to confirm when a patched image is available.
7. Apply Short‑Term Mitigations
- On non‑Raspberry Pi systems where the driver is a loaded module and not needed, blacklist it by creating
/etc/modprobe.d/blacklist-clk-raspberrypi.confwith the lineblacklist clk-raspberrypiand then unloading the module withmodprobe -r. - On Raspberry Pi, the driver is essential for hardware operation, so blacklisting is not an option. Restrict local user access and heighten monitoring for kernel oops messages:
dmesg | grep -i oops. - For containers and multi‑tenant hosts, remove unnecessary device access from untrusted workloads.
8. Integrate Microsoft’s VEX into Your Workflows
Subscribe to Microsoft’s CSAF/VEX feed if your vulnerability scanner supports it. This will automate re‑checks when Microsoft expands its attestations for CVE‑2025‑38160 or other vulnerabilities. Until then, treat any non‑attested Microsoft image as unverified and run your own scans.
Outlook
Microsoft’s phased VEX rollout is a meaningful improvement for open‑source vulnerability transparency, but it places a temporary verification burden on IT teams. Expect the list of attested products for this CVE to grow as the company completes its inventory. In the meantime, make image‑level scanning part of your routine—because a single NULL check can be the difference between a stable cloud and a crashing one.