Microsoft’s advisory that the Azure Linux (CBL‑Mariner/Azure Linux) distribution is the only
Microsoft‑identified product containing the impacted Linux kernel component is accurate as a current, public attestation — but it is not a technical guarantee that no other Microsoft product ships the same vulnerable kernel code. The vulnerability in question, registered as
CVE‑2025‑38634, is an upstream Linux kernel fix to the CPCAP charger driver that corrects a missing null check for power_supply_get_by_name, and whether any Microsoft product is affected depends on whether that product ships a kernel tree and configuration that includes the driver prior to the upstream fix.
Background / Overview
CVE‑2025‑38634 is classed as a kernel issue in the Linux power-supply code: the change makes a defensive null check in the CPCAP PMIC charger driver’s cpcap_usb_detect path because power_supply_get_by_name("battery") may return NULL instead of an error pointer in some code paths. A null pointer dereference here can cause a local crash (denial of service) and in theory may lead to broader instability depending on workload and device configuration. The upstream patch and its inclusion into the stable kernel trees were merged in the 6.x stable branches and subsequently propagated to vendor distributions. Why this matters: the CPCAP charger driver (module name cpcap‑charger; kernel config symbol CONFIG_CHARGER_CPCAP) is an optional kernel module that targets specific mobile PMIC hardware (Motorola/CPCAP family, historically seen on some OMAP/phone platforms). If a kernel build includes that module and the kernel version predates the upstream fix, the binary shipped could contain the vulnerable code. Whether any Microsoft product is affected therefore comes down to which kernel source, commit range and kernel configuration Microsoft used when building product kernels.
The technical fix and upstream status
What changed upstream
- The upstream commit fixes a logic check in drivers/power/supply/cpcap‑charger.c within the cpcap_usb_detect routine: the code now explicitly checks for NULL return values from power_supply_get_by_name("battery") and returns early with an error log rather than attempting to dereference the pointer. This is a classic defensive fix for potential null pointer dereference. The patch is small, but it was cherry‑picked into the stable trees because it addresses a robustness/security issue.
Where the fix landed
- The change was applied to multiple stable kernel trees (6.6, 6.12, 6.16 and other stable backport branches) and is referenced in public stable‑commit lists and kernel commit logs. Distributions tracking those trees have rolled the change into their kernel updates. That means any distribution packaging kernels from those fixed commits is not vulnerable once the vendor's update is applied.
Practical impact
- This is a local‑only vector (the module’s behavior is tied to platform battery detection and driver callbacks). It is not a remote network‑facing exploit in the usual sense. However, local denial‑of‑service on server or embedded platforms where the module is present can be disruptive. Distributions that do not enable the cpcap charger driver in their kernel configuration are unaffected.
Who ships this code: where the module lives and how to tell
The cpcap‑charger driver and kernel configuration
- The CPCAP charger driver is exposed behind Kconfig as CONFIG_CHARGER_CPCAP and builds the module cpcap‑charger. It depends on several platform/arch options (it is tied to MFD CPCAP support and, historically, OMAP/ARM platforms), so it’s commonly enabled only in kernels targeting mobile/embedded ARM platforms. The Linux Kernel Driver Database (LKDDb) documents CONFIG_CHARGER_CPCAP as a tristate option and notes the module name and the driver path.
How to confirm presence on a running system (technical verification)
For any product or image you control (including Microsoft‑shipped kernels), verify either of the following:
- Inspect the kernel config shipped with the kernel (common locations):
- /boot/config-$(uname -r)
- or extract the .config from the kernel package or image and search for CONFIG_CHARGER_CPCAP.
- Check present modules and drivers:
- Run lsmod and grep for cpcap_charger (module may be listed as cpcap_charger or cpcap‑charger depending on build name).
- Search /lib/modules/$(uname -r)/kernel/drivers/power/supply/ for cpcap‑charger.ko
- If you have kernel source for the build, search drivers/power/supply/cpcap‑charger.c for the affected function and compare commit history to know whether your version contains the vulnerable code.
These checks are required because the driver is optional and platform‑specific;
presence is determined by the kernel build configuration, not just the kernel version number.
Microsoft’s public position (what Microsoft has said so far)
Microsoft’s security guidance for CVE‑2025‑38634 explicitly mentions that its Azure Linux distribution (formerly CBL‑Mariner) is a product that includes the upstream component and that Microsoft publishes CSAF/VEX attestations for Azure Linux — and that if other Microsoft products are discovered to include the affected component Microsoft will update the CVE and its guidance. That is a measured, attestation‑based statement: Microsoft has publicly
confirmed Azure Linux as an inclusion point but has not publicly declared that no other Microsoft product contains the vulnerable driver. (The user quote you supplied is the verbatim summary of Microsoft’s attestation.
This is consistent with how vendors manage third‑party open source components: they attest presence only for product artifacts they have tested and are ready to publish, and leave the door open to update their VEX/CSAF attestations if additional products are found to contain the same component. The attestation approach is transparent but not equivalent to a complete guarantee of absence across all Microsoft artifacts.
Is Azure Linux the ONLY Microsoft product that could be affected?
Short answer: No — Azure Linux is not necessarily the only Microsoft product that could ship the vulnerable code; it is the only Microsoft product Microsoft has publicly attested as including the component so far. Whether any other Microsoft product actually contains the vulnerable driver is a question of the kernel source/commit range and the kernel configuration used by that product.
Key Microsoft artifacts that warrant scrutiny:
- Azure Linux (CBL‑Mariner / AzureLinux) — Microsoft has publicly attested that this distro includes the affected upstream kernel components. Microsoft is actively publishing security attestations for Azure Linux builds and will update them if more product impacts are discovered.
- Windows Subsystem for Linux (WSL2) — Microsoft ships a Microsoft‑built Linux kernel for WSL2; the kernel source, configuration files and build scripts for the WSL kernel are publicly available in the microsoft/WSL2‑Linux‑Kernel repository. Whether the WSL kernel build includes CONFIG_CHARGER_CPCAP (or the cpcap‑charger module) depends on the WSL kernel configuration selected by Microsoft for the release in question. In practice, WSL kernels are relatively minimal and focused on x86_64 desktop/server features, so many architecture‑specific embedded ARM modules are routinely omitted, but the only way to be certain is to inspect the exact Microsoft config used in the WSL build.
- CBL‑Mariner / Azure Linux variants used by Azure services / host images / container hosts — CBL‑Mariner (now evolving under Azure Linux branding) is used across a range of Microsoft infrastructure and container base images. Azure services or host images that include a kernel built from an upstream tree that contained the vulnerable commit — and that enabled the CPCAP driver — would carry the code until vendor patches are applied. Microsoft’s internal distro choices and the kernel configurations used for specific host images determine the exposure.
- Other Microsoft Linux artifacts — Microsoft also maintains other Linux artifacts (images, container base images, tooling) where a particular kernel or kernel module might be present. Each needs per‑artifact verification.
In short: Azure Linux is the
only Microsoft product Microsoft has told us includes the component, but several Microsoft products or artifacts are plausible carriers and should be checked by customers and administrators who need to be certain.
How to verify Microsoft products you rely on (practical steps)
If you manage systems or images where a Microsoft‑supplied Linux kernel is running — or if you consume Microsoft container base images — verify exposure as follows:
- For a running instance (VM, container host, WSL instance):
- Check the kernel release: uname -a
- Inspect /boot/config-$(uname -r) or run zcat /proc/config.gz if available and search for CONFIG_CHARGER_CPCAP.
- Check for the module file:
- ls /lib/modules/$(uname -r)/kernel/drivers/power/supply | grep cpcap
- If module is present, run modinfo cpcap‑charger (or modinfo cpcap_charger) to get the exact built‑from kernel version and signature.
- For WSL2:
- Confirm the WSL kernel package/version used (wsl --status and uname inside WSL).
- Inspect the modules VHD (if Microsoft provided it) or check /lib/modules as above.
- Review Microsoft’s WSL kernel repo & Microsoft/config‑wsl for the kernel config used by the specific WSL release if you need to audit the build config.
- For managed Azure images:
- Consult vendor advisories and kernel package metadata (Azure image details and security updates) and apply vendor updates as they are released.
- If you operate dedicated appliances or base images derived from CBL‑Mariner/Azure Linux, use your image pipeline to inspect installed kernel packages (rpm -q kernel; rpm -ql kernel | grep drivers/power/supply) and apply vendor updates promptly.
If any of these checks show the cpcap module or a kernel version earlier than the fixed commit and the vendor has not yet released a patch, treat the system as potentially exposed and follow the mitigation steps below.
Mitigations and recommended actions
- Apply vendor updates: The authoritative fix is the vendor backport or the upstream fixed kernel. Distributions that track the fixed stable trees have released updated kernels; apply those updates through your normal update processes. Debian, Ubuntu, SUSE and other distributions have recorded fixes in their security trackers and advisories. If you run Azure Linux, ensure you consume Microsoft’s published update that contains the fix.
- Disable or blacklist the module (short‑term): If a system does not need the CPCAP charger driver (typical for x86 servers, cloud images and WSL), consider blacklisting the module to prevent it from loading. Add a blacklist entry in /etc/modprobe.d/ (example: blacklist cpcap_charger) — note that on systems where the driver is built‑in or required for real hardware, this is not suitable.
- Rebuild custom kernels without the option: For teams that build custom kernels (including WSL custom kernels), remove CONFIG_CHARGER_CPCAP from the .config and rebuild, or update your base to a kernel that contains the upstream fix.
- Configuration and inventory: Treat this as a component‑presence problem: inventory kernels and module presence across Microsoft images you consume and apply the above checks on a regular cadence. Where you can't inspect the kernel directly (managed or closed images), rely on vendor attestations and CVE/VEX/CSAF updates; Microsoft has stated it will update its VEX attestations as further impact is discovered.
Risk assessment — strengths and potential gaps
Strengths
- The upstream fix was small and merged quickly into several stable trees — this makes vendor backports straightforward and lowers the operational cost of remediation.
- The CPCAP driver is fairly specialized (mobile/embedded PMIC) and is not commonly enabled in general‑purpose server or desktop kernels; that reduces the global attack surface compared with a widely used networking or filesystem driver. The Linux vendor landscape (Debian, SUSE, Ubuntu, etc. has already propagated fixes to stable packages.
Potential risks / gaps
- The primary risk is a lack of visibility into every product artifact that a large vendor ships. Microsoft publishes attestations for Azure Linux and is committed to VEX/CSAF transparency; however, other Microsoft artifacts (for example kernel builds for WSL, or host kernels used in specific Azure managed services) could conceivably include the driver if they were built with the option enabled — and until those artifacts are inspected and attested, customers must either verify or rely on vendor disclosure. This is not a criticism of the vendor’s process; it is simply the nature of modern software supply chains.
- Another operational risk is complacency: because many cloud images are x86_64 and many CPCAP features target ARM/mobile, administrators might assume the driver cannot be present — but assumptions are brittle. The correct approach is measurement (inventory + config checks), not assumption.
What to look for in vendor statements and CSAF/VEX attestations
When a vendor (Microsoft or otherwise) publishes an attestation for a CVE, check these points in the attestation:
- Which exact product artifacts were scanned (product name, exact image tags, kernel package/version)? VEX/CSAF should list product IDs and artifact hashes where possible.
- Which versions are marked “affected”, “not affected”, or “under investigation”?
- Timeline and cadence for pushing fixes — for kernel vulnerabilities that are backported to stable trees, vendors typically list the fixed kernel package version or remediation guidance.
- If a vendor says “we have not identified this component in other products,” prefer a clear statement of the verification methodology or a promise to update the attestation when more evidence is available. Microsoft’s existing wording follows this pattern: Azure Linux is confirmed; if additional products are found to be impacted Microsoft will update the CVE and attestations. That is the correct transparency behavior, but customers must actively track updates.
Conclusion
CVE‑2025‑38634 is a legitimate upstream Linux kernel fix for a missing null check in the CPCAP charger driver (cpcap‑charger). Microsoft has publicly attested that its Azure Linux distribution includes the relevant upstream component; that attestation is the authoritative statement Microsoft has made to date. However, because Microsoft ships multiple Linux artifacts (the WSL kernel, CBL‑Mariner/Azure Linux variants used across Azure, container base images and other kernels), it would be incorrect to assume Azure Linux is the
only Microsoft product that could possibly include the module — containment depends on the kernel configuration and commit range used for each shipped artifact.
Customers and administrators should therefore:
- Inspect kernels and modules on systems they manage (exact steps are listed above).
- Apply vendor kernel updates once published (distributions have already backported fixes to their stable packages).
- Rely on Microsoft’s ongoing VEX/CSAF attestations for Azure Linux and watch for updates regarding other Microsoft artifacts.
The practical reality is straightforward: if your systems do not include the CPCAP module, you are not affected; if they do, update the kernel or blacklist/remove the module until a vendor patch is applied. Microsoft’s transparency stance (attesting Azure Linux and committing to update the CVE if impact to additional products is identified) is appropriate; customers who need absolute assurance should verify the kernel configuration for each Microsoft‑supplied artifact they depend on.
Source: MSRC
Security Update Guide - Microsoft Security Response Center