A null-pointer dereference bug in the Linux kernel’s ATM “clip” code — tracked as CVE-2025-38458 — has been fixed upstream, and Microsoft’s Security Response Center (MSRC) has published a short product-level attestation saying
Azure Linux includes this open‑source library and is therefore potentially affected while promising to publish machine‑readable VEX/CSAF attestations and to update the CVE mapping if other Microsoft products are identified as impacted.
Background / Overview
The vulnerability lives in the ATM networking stack inside the Linux kernel: specifically, a NULL pointer dereference in the vcc_sendmsg path in the ATM CLIP code (net/atm/clip.c). The bug arises when the atmarpd_dev_ops implementation does not provide a valid send method and the code later calls through that ops pointer, producing an oops/NULL-deref and a kernel crash. Upstream manifests and vendor advisories characterize the issue as a
crash/denial‑of‑service rather than a remote code‑execution exploit, and the call trace published in public advisories points to net/atm/common.c / net/atm/clip.c in the vcc_sendmsg call path. The Linux kernel community has published fixes in the upstream tree and backported patches to multiple stable branches; kernel maintainers recommend updating to a patched stable kernel release rather than attempting to cherry‑pick individual commits. Several downstream distributors (Debian, SUSE, Oracle, Red Hat derivatives) have published advisories and package updates that correspond to the same upstream fix.
What exactly is CVE‑2025‑38458?
Technical summary
- Component: Linux kernel — ATM CLIP (net/atm/clip.c, vcc_sendmsg).
- Type: NULL pointer dereference — kernel oops / crash.
- Root cause: The atmarpd_dev_ops (ATM ARP daemon device operations) structure may not implement a send callback; vcc_sendmsg calls that function (through vcc->dev->ops->send) without validating it, producing a NULL dereference in some code paths. The typical trigger involves a failure path in userspace → kernel data copy → skb processing where the expected revert/cleanup is not reached, leaving the code to call a non‑existent ops->send.
Practical impact
- Impact class: Denial‑of‑service (kernel crash). Most public scoring engines list this as moderate to medium impact because the bug causes crashes but does not, on the published evidence, provide a direct code‑execution primitive. The attack surface is limited to kernels that have the ATM CLIP code enabled and present; on kernels where ATM support is compiled out or built as out‑of‑tree or disabled, the vulnerability is not reachable.
Microsoft’s public mapping: what did MSRC say?
Microsoft’s publicly visible advisory entry for CVE‑2025‑38458 includes an FAQ line that reads, in essence, that
Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability, and that Microsoft began publishing machine‑readable CSAF/VEX attestations for Azure Linux in October 2025 and will update mappings as additional product impacts are identified. That wording is short and deliberately conservative: it states a
confirmed inclusion for Azure Linux but does not enumerate other Microsoft products or claim exclusivity. Microsoft’s broader transparency program — the CSAF + VEX rollout — means MSRC is now publishing product‑level attestations for third‑party CVEs so customers can quickly learn whether a Microsoft product is
known to include an affected upstream component and the current exploitability/patch status for that product. The MSRC blog explains that Microsoft began with Azure Linux (formerly CBL‑Mariner) and plans to scale attestations to additional products over time.
Is Azure Linux the only Microsoft product that includes the vulnerable library?
Short answer:
No — not necessarily. The MSRC statement confirms Azure Linux as a
known affected Microsoft product; it does
not logically or technically establish that no other Microsoft product includes the same upstream code. Microsoft has committed to publish VEX attestations for the products it inspects and will update those attestations if and when other Microsoft artifacts are found to include the same vulnerable component. In other words: Azure Linux is the only Microsoft product Microsoft has publicly attested so far for this CVE, but Microsoft’s one‑line mapping is an attestation, not an exhaustive guarantee of exclusivity.
Why that distinction matters
- An MSRC product mapping is a product‑level inventory result — it documents what Microsoft has verified for that specific product. It does not demonstrate (and is not required to demonstrate) that other Microsoft distributions, images, or kernel builds are free from the same code.
- Microsoft distributes several Linux‑kernel artifacts that are distinct from Azure Linux — most notably the WSL2 kernel builds, Azure guest images, and the kernels used by container/VM images and managed services. Those artifacts are maintained and built with different configurations and release cadences; some may include ATM code depending on build config and kernel version.
Which other Microsoft artifacts could plausibly include the vulnerable code?
Several Microsoft‑maintained artifacts could — depending on kernel version and configuration — include the ATM CLIP code path:
- WSL2 kernel builds (microsoft/WSL2‑Linux‑Kernel): Microsoft maintains and ships a Linux kernel for WSL2; the repo and releases show that Microsoft publishes explicit kernel branches and release tags. Whether a particular WSL kernel build carries the ATM subsystem depends on the kernel version and kernel config used in that WSL build. Because Microsoft is the steward of the WSL2 kernel artifact, any inclusion of the vulnerable net/atm code in the WSL kernel would mean WSL kernels need the same evaluation and, if necessary, a patch.
- Azure VM images and kernel packages: Azure publishes multiple Linux images (official distro images and Microsoft‑maintained images such as Azure Linux). The kernel versions used in those images vary by image family and update cadence; image maintainers must map vulnerable upstream commits to their own kernels to decide patching/backporting. Microsoft’s Azure Linux attestation clarifies one family, but other Azure images (for example, marketplace images or customized kernels used by certain IaaS offerings) should be inventoried and patched as needed.
- Container host/node images (AKS/Azure Linux container host): Microsoft documents specific Azure Linux container host images for AKS; if an AKS node image uses an Azure Linux kernel image or includes the ATM component, those nodes are in scope for remediation. The AKS node image lifecycle and support policy will determine how long unpatched images remain.
Because Microsoft’s public mapping process starts with Azure Linux and is being expanded incrementally, a prudent defender should
assume other Microsoft Linux artifacts might include the same upstream code until explicitly attested otherwise.
What the upstream and distributors say about fixes
- The Linux kernel team and kernel‑security trackers list the bug, identify the affected file (net/atm/clip.c), and show the set of upstream commits that fix the issue. Upstream commentary states the issue was introduced long ago (historical blame points) and was fixed in recent stable releases; the kernel CVE announcement recommends updating to the latest stable kernel release and warns against cherry‑picking individual commits unless you know what you’re doing.
- Multiple distributors have shipped patched kernel packages or published advisories: Debian, SUSE, Oracle, and other downstream vendors have published security notices and package updates. Those vendor pages list the same problem description and provide package‑level remediation guidance.
Practical takeaway: the correct remediation for production systems is to install the vendor‑provided patched kernel or update to an upstream stable kernel that contains the fix. Backporting or cherry‑picking the commit is possible for expert kernel maintainers but is error‑prone and discouraged for most users.
Recommended actions for administrators and incident responders
- Inventory and identify
- Confirm whether your environment runs any Microsoft‑distributed Linux artifacts: Azure Linux container hosts (AKS node images), Azure VM images that use Azure Linux, Microsoft‑distributed WSL2 kernel builds, and any custom images built from Microsoft artifacts. If you’re unsure which kernel binary a VM or node uses, query /proc/version and the distribution package manager kernel package version.
- Map kernel versions to upstream fixes
- Use the kernel CVE/patch references to map whether a given kernel version includes the upstream fix. If vendors have published patched kernel packages for your distro, prefer those vendor packages to manual backports. Upstream kernel CVE notices include the specific commits and recommended stable releases that contain the patch.
- Patch with vendor packages
- Apply the official security updates from your Linux distribution vendor (or from Microsoft for Azure Linux) as soon as practical. For Azure customers, apply the Azure Linux updates published via Microsoft’s normal image and package channels. If you use WSL2 and Microsoft has released a patched WSL kernel, update via the mechanisms Microsoft documents (WSL kernel updates, Windows Update where applicable).
- If you cannot patch immediately, mitigate and monitor
- If ATM networking is not used in your environment, you can reduce risk by disabling the ATM modules or blacklisting the relevant kernel modules where practical. Monitor kernel logs (dmesg) for oops or crash signatures referencing vcc_sendmsg or net/atm to detect exploitation attempts or crashes. Note that disabling kernel functionality may have downstream operational impacts and must be tested.
- Track Microsoft’s VEX/CSAF attestations
- Microsoft publishes CSAF/VEX attestations that state the vulnerability status for Azure Linux and — over time — other Microsoft products. Subscribe to MSRC advisories and the Microsoft provider CSAF/VEX feeds to receive machine‑readable mapping updates, and treat those attestations as authoritative for the product they cover. However, do not interpret an absence of an attestation for other products as proof of non‑inclusion; rather, treat it as not yet attested and follow inventory/patch processes for other artifacts.
How to interpret Microsoft’s wording in security advisories
Microsoft’s one‑line statement on the MSRC CVE page is a
product attestation, not a full inventory audit for all Microsoft software. Key interpretive points:
- Attestation vs. Exhaustive Claim: When MSRC says “Azure Linux includes this open‑source library and is therefore potentially affected,” it is telling customers that Microsoft has validated that this product contains the upstream component associated with the CVE. It does not assert that no other Microsoft products include the same code. Microsoft’s public commitment to update the CVE entry if additional product impacts are identified means that their mapping can and will change.
- Why Microsoft begins with Azure Linux: The VEX/CSAF program started with Azure Linux as the initial target for machine‑readable attestations because the distribution is a Microsoft‑owned Linux artifact with a well‑bounded supply chain. Microsoft’s blog explains the phased rollout and the intention to expand attestations to other products over time. Customers and vendors should treat the VEX statements as authoritative for the specific product they cover.
- Defensive stance for downstream customers: If you run Microsoft‑branded Linux artifacts beyond Azure Linux (WSL kernels, Azure images, managed nodes), don’t rely solely on MSRC wording; validate the kernel version, check vendor advisories, and patch according to your software supply‑chain rules. The MSRC attestation is useful and authoritative where present, but it’s not a substitute for local inventory and patching practices.
Risks, limitations, and open questions
- Limited exploitation potential but real DoS risk: Public evidence shows a NULL dereference that causes kernel crashes — a dependable denial‑of‑service vector. There is no public proof the bug gives an RCE primitive, but kernel crashes in production systems (especially multi‑tenant clouds) have serious operational effects.
- Configuration and build variance matter: Whether a particular Microsoft artifact is vulnerable depends on whether the ATM CLIP code is present in the kernel binary (compiled‑in or as a module), and whether that specific version contains the vulnerable commit. Microsoft’s attestation for Azure Linux confirms inclusion there; other Microsoft kernels require binary/branch inspection. This complexity is why CSAF/VEX is valuable: it ties a vulnerability to a specific product and version.
- Vendor patching cadence and backports: Downstream vendors frequently backport security fixes into older kernel branches. For operators, that means you must track vendor advisories for the exact package names and kernel ABI versions in your environment; upstream‑level version numbers are necessary but not always sufficient to determine whether a shipped kernel includes the fix.
- Unverifiable claims to flag: If a third party claims that all Microsoft products are unaffected or that this CVE affects only Azure Linux and no other image ever, those are unverifiable from MSRC’s single attestation alone. Conversely, any public claim that a specific Microsoft product other than Azure Linux is affected should be expected to be backed by either an MSRC VEX attestation or vendor‑provided evidence (e.g., the WSL kernel tag shows the offending code). Until MSRC publishes attestations for other products, independent verification via version and config inspection is the safest route.
Conclusion and practical checklist
CVE‑2025‑38458 is a kernel NULL pointer dereference in the ATM CLIP code that causes crashes; upstream fixes exist and distributors have shipped patched packages. Microsoft’s MSRC has publicly attested that
Azure Linux includes the vulnerable upstream component and is therefore potentially affected, and Microsoft is publishing CSAF/VEX attestations to make that mapping explicit and machine‑readable. That attestation does not prove that
no other Microsoft product includes the vulnerable code — it confirms a
known inclusion for Azure Linux and commits Microsoft to expand attestations as additional artifacts are validated. Immediate checklist for defenders:
- Inventory your Microsoft‑distributed Linux artifacts (Azure Linux images, WSL2 kernel builds, AKS node images).
- Check kernel versions against upstream fix commits and vendor advisories.
- Apply vendor‑provided patched kernels or prefer full kernel upgrades to patched stable releases.
- If patching is delayed, disable ATM modules where feasible and monitor kernel logs for crash indicators.
- Subscribe to MSRC CSAF/VEX feeds and vendor security trackers for updated attestations and CVE mappings.
Staying pragmatic: treat MSRC’s attestation for Azure Linux as authoritative for that product, but continue to do the work of inventory and validation across other Microsoft‑managed kernels and images until Microsoft’s VEX program has completed coverage for the broader product surface.
Source: MSRC
Security Update Guide - Microsoft Security Response Center