CVE-2025-38460: Linux ATM CLIP Null Pointer Fix and Azure Linux Attestation

A short, unchecked null-pointer dereference in the Linux kernel’s ATM CLIP code — tracked as CVE‑2025‑38460 — has been assigned and fixed upstream, and Microsoft’s public guidance confirms Azure Linux as a confirmed attested product that includes the affected open‑source library; however, Azure Linux is not technically guaranteed to be the only Microsoft product that could include the vulnerable code. The true exposure depends on whether other Microsoft products ship a Linux kernel (or kernel modules) built from a vulnerable kernel tree and with the ATM/CLIP code enabled, and whether those kernels are older than the upstream fixes that close the bug.

Background / Overview​

CVE‑2025‑38460 is a Linux‑kernel memory safety issue in the ATM (Asynchronous Transfer Mode) CLIP code path. The problem arises from a potential null‑pointer dereference in the helper function to_atmarpd, which can be invoked from unsleepable contexts such as clip_neigh_solicit and neigh_ops->solicit. The upstream kernel team fixed the defect by adding appropriate locking (a private mutex + RCU protection) to guard access to the atmarpd pointer. The Linux CVE announcement lists the fix commits and the kernel stable branches where the patch was applied. Why this matters practically: the ATM CLIP code is a niche network subsystem (mostly relevant to ATM networking stacks and legacy environments). Whether a given product is actually exploitable depends on three conditions:

• The product contains a Linux kernel build that includes the ATM/CLIP sources (the code is present in the tree).
• The kernel config used to build that kernel enabled the ATM / CLIP functionality (built‑in or as a module).
• The shipped kernel version predates the upstream fixes listed for this CVE (see fixed versions below).

If all three are true, the product can be considered in scope; if any is false, the product is not exposed to this bug.

Fixed kernel versions (upstream)​

The Linux kernel CVE announcement maps the fix to specific stable series and commits; upstream fixes were applied as follows (representative entries):

• Fixed in 5.4.296 (commit a4c5785…)
• Fixed in 5.10.240 (commit 70eac9b…)
• Fixed in 5.15.189 (commit 3251ce3…)
• Fixed in 6.1.146 (commit ee4d9e4…)
• Fixed in 6.6.99 (commit 06935c5…)

Use these kernel version boundaries when determining whether a kernel is new enough to include the upstream fix.

---

What Microsoft has said (short answer)​

Microsoft’s official MSRC advisory wording follows a pattern used for multiple Linux CVEs: Microsoft has attested that Azure Linux (the Microsoft‑maintained distro formerly known as CBL‑Mariner / Azure Linux Distribution) includes the offending library and therefore requires attention. In the advisory FAQ Microsoft explicitly calls out Azure Linux as the product they are attesting today and states that they will update the CVE/VEX entries if additional Microsoft products are found to be impacted. That attestation is authoritative for Azure Linux customers, but it is not an exhaustive guarantee that no other Microsoft product could include the vulnerable code. This distinction is deliberate: Microsoft has begun a phased rollout of machine‑readable VEX/CSAF attestations that presently start with Azure Linux; other Microsoft products will be inventoried and onboarded over time. The result is that Azure Linux is the only Microsoft product explicitly attested at time of publication, but absence of an attestation is not proof of absence — other Microsoft products that ship or embed a Linux kernel must be validated on a per‑product basis.

---

Deep technical analysis — how to decide exposure​

Determining whether a Microsoft product beyond Azure Linux is affected is a practical exercise that combines inventory, kernel version checks, and kernel‑config verification. The following sections explain the checks and provide commands and procedural steps administrators and security teams can follow.

1) Inventory: which Microsoft products ship a Linux kernel?​

Microsoft publishes and ships Linux kernel artifacts in several places:

• The Microsoft WSL2 kernel (Windows Subsystem for Linux 2) — Microsoft maintains the kernel source and builds for WSL2. WSL2 kernels are public in the microsoft/WSL2‑Linux‑Kernel repository and are distributed as part of WSL2.
• Azure Linux images (attested by MSRC) — Microsoft’s Azure Linux distribution is published and maintained by Microsoft and is the first product to receive CSAF/VEX attestations.
• Some Azure offerings and appliance‑style images use kernels that Microsoft packages or distributes (for example, node images for AKS that embed Azure Linux, Microsoft ship‑images for Azure Marketplace, or internal appliance kernels used by cloud services).
• Any other Microsoft product or offering that bundles a Linux kernel image (rare, but possible in appliance or container host scenarios).

If a Microsoft product ships a Linux kernel image, that kernel must be checked for the presence of the vulnerable code and for the kernel version in use.

2) Kernel version check (compare against upstream fixes)​

On a target Linux instance (VM, WSL2 instance, Azure Linux host), determine the running kernel version:

• uname -r
• If you have a boot config file: zgrep "^CONFIG_" /proc/config.gz or cat /boot/config-$(uname -r) (depending on distro).

If the running kernel is older than the fixed versions listed earlier (e.g., it is on a 5.15 series prior to 5.15.189 or a 6.6 series prior to 6.6.99), then continue to step 3. If the kernel is equal or newer than the fixed release for that series, the upstream fix is already present.

3) Kernel config check — was ATM/CLIP enabled?​

Presence of the source in the kernel tree is necessary but not sufficient — the kernel must be configured to build the ATM/CLIP component. Check for the following config options in the kernel config:

• CONFIG_ATM
• CONFIG_ATM_CLIP (or related CONFIG options referencing clip)

Common commands:

• On systems with /proc/config.gz:
• zgrep -i 'CONFIG_ATM' /proc/config.gz
• On distros that install /boot/config-$(uname -r):
• grep -i 'CONFIG_ATM' /boot/config-$(uname -r)
• For WSL2 (if you are using Microsoft’s kernel repository), check the repository’s .config for the release tag in use (or query the WSL kernel package’s modules list).

If CONFIG_ATM or CONFIG_ATM_CLIP is set to 'y' (built‑in) or 'm' (module), the ATM CLIP code may be present and loadable. If neither option appears, the kernel was built without ATM support and is not exposed. Note that some distros may compile ATM code behind another CONFIG option or include it statically; consult the distro’s kernel config documentation when in doubt.

4) Module presence at runtime​

If the kernel supports loadable modules, check whether an ATM or CLIP module is present:

• lsmod | grep -i atm
• modinfo <module-name> (where module-name might be clip, atm, or another distributed name)
• find /lib/modules/$(uname -r) -type f -name 'clip.ko' -o -name 'atm.ko'

If a clip‑related module is installed in /lib/modules and can be loaded, it indicates a potential exposure vector until patched. If you cannot identify the exact module name, the kernel config check above is the definitive method.

---

Are other Microsoft products likely to be affected?​

Short technical answer: yes, it's possible. Any Microsoft product that ships a Linux kernel matching the conditions in section “Deep technical analysis” could be affected. Concrete examples to evaluate:

• WSL2 (Windows Subsystem for Linux): Microsoft maintains a published WSL2 kernel and ships kernel binaries as part of WSL. Whether a given WSL2 kernel image is affected depends on the WSL kernel version and its config; many modern WSL2 kernels are in the 6.6.x series and Microsoft releases regular updates. Customers should check their WSL kernel version with uname -r and compare to the upstream fixes.
• Azure Marketplace VM images: Many Azure images are simply distro images (Ubuntu, Debian, etc.. The upstream distro vendor (Ubuntu/Debian) is the primary maintainer of those kernels; however, Azure customers should watch both Microsoft and the distro vendor advisories because the distro kernel in the image is the exploitable artifact. (Ubuntu and other vendors have published advisory entries for this CVE and list affected kernel packages and fixed package names.
• Appliance‑style or internal cloud images: Any Microsoft product that embeds a kernel build could theoretically be impacted until the vendor confirms the kernel build is patched or the ATM/CLIP code is disabled.

Microsoft’s published MSRC advisory is intentionally conservative in language: Azure Linux is the only Microsoft product currently attested to include the upstream component for this CVE, and Microsoft will update the CVE / VEX attestation if further impact is identified. That means Azure Linux customers have a clear remediation path; administrators of other Microsoft offerings should verify individually.

---

Recommended actions and mitigations​

The following steps are prioritized for defenders responsible for Microsoft-hosted environments, WSL users, and Azure customers.

For Azure Linux customers (highest priority)​

• Check MSRC/VEX/CSAF feeds for Azure Linux attestation and the Microsoft security update guide for precise package/kernel updates delivered for Azure Linux. Apply the kernel update or hotpatch provided by Microsoft for Azure Linux images as soon as it becomes available and tested in your environment. Microsoft’s VEX/CSAF feed is the authoritative, machine‑readable attestation for Azure Linux.

For WSL2 users (Windows desktops/servers)​

• Check your WSL kernel version:
• Open a WSL terminal and run uname -r
• If your kernel is older than the fixed upstream version for its series (see section above), update WSL:
• Run wsl --update and/or update Windows to pull the newest WSL kernel that Microsoft publishes.
• If you use a custom WSL kernel (configured in %USERPROFILE%.wslconfig), rebuild or replace it with a fixed build (use the microsoft/WSL2‑Linux‑Kernel sources or an updated distribution kernel compiled with ATM disabled or patched).

For Azure VM image / AKS node operators​

• Treat these as you would any Linux kernel CVE: identify which node images/VM images you run, check each image’s kernel version and config, and apply vendor (Ubuntu/Debian/Microsoft) security updates or node image updates. For AKS node pools that use Azure Linux, follow Microsoft’s node image updates guidance and ensure your node pools are patched or reprovisioned with updated node images.

Short-term mitigations (if patching is not immediately possible)​

• If the kernel exposes CLIP as a loadable module and it is not required, unload it and blacklist it:
• sudo modprobe -r clip (or the actual module name if different)
• Add the module to /etc/modprobe.d/blacklist.conf to prevent loading on reboot.
• If the ATM/CLIP code is built into the kernel, runtime removal is not possible; prioritize patching.
• Apply standard defense‑in‑depth controls: restrict privileged local accounts, monitor dmesg and syslogs for OOPS or NULL‑dereference traces, and reduce attack surface for local network interfaces that might invoke the ATM code.

---

Risk, severity, and exploitability​

Upstream announcements describe the issue as a potential null‑pointer dereference in a relatively specialized networking path. Publicly published triage information shows a variety of CVSS and EPSS scoring attempts; some vendor pages list moderate severity ratings. The intrinsic exploitation model is constrained by the fact that the vulnerable function is typically triggered in local and unsleepable contexts, which makes remote exploitation less straightforward and likely requires local privileges or local network conditions that reach into the ATM stack. That said, a producer of a denial‑of‑service or kernel crash is plausible and should be treated seriously in environments where the ATM/CLIP stack is present. Practical implication for Microsoft environments: if a product ships a kernel that includes ATM/CLIP and that kernel predates the fixed upstream versions, it should be treated as in scope regardless of perceived exploitation difficulty. Microsoft’s attestation model ensures Azure Linux customers have a clear update path; other Microsoft product owners must validate their kernel images as described earlier.

---

Why Microsoft’s wording doesn’t mean “only Azure Linux is affected”​

Microsoft’s public advisory text and CSAF/VEX rollout make an important operational distinction:

• The attestation “Azure Linux includes this upstream library” is an affirmative statement — it tells customers where Microsoft has already completed inventory and validation for this CVE.
• The absence of an attestation for other Microsoft products is not an affirmative denial of inclusion — it simply means those products have not yet been onboarded to the machine‑readable VEX/CSAF attestation service at publication time. Microsoft explicitly says it will update CVE entries if impact to additional products is identified. This is a pragmatic, phased transparency rollout rather than a technical guarantee that no other Microsoft product bundles the same vulnerable component.

For security teams that need definitive answers for non‑Azure‑Linux Microsoft products, the pragmatic path is to (a) identify whether the product ships or embeds a Linux kernel artifact, and (b) validate the kernel version and config using the checks laid out above.

---

Practical checklist (what to do now)​

• Inventory Microsoft assets in your environment that run or embed a Linux kernel: Azure Linux nodes, WSL2 instances, appliance images, VM images, AKS node pools.
• For each asset, run uname -r and compare the kernel series/version against the upstream fixed versions (5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99).
• Check kernel configs (/proc/config.gz or /boot/config-*) for CONFIG_ATM / CONFIG_ATM_CLIP presence.
• If ATM/CLIP is present and kernel is older than fixed versions, prioritize patching or use the temporary module blacklist/unload mitigation.
• Monitor MSRC / CSAF / VEX feeds and your distro vendor advisories (Ubuntu/Debian/Red Hat) for targeted remediation guidance, and apply vendor/MSRC patches as they are published.

---

Conclusion — practical takeaways for WindowsForum readers​

• CVE‑2025‑38460 is a real but specialized Linux kernel vulnerability in the ATM CLIP code. Upstream kernels have been fixed across multiple stable branches; the fix is mapped to specific kernel‑series and commits upstream.
• Microsoft has attested that Azure Linux includes the affected library and will provide updates via MSRC and Azure Linux image updates; this gives Azure Linux customers a direct remediation path. That attestation does not categorically exclude other Microsoft products from being affected. Microsoft’s VEX rollout intentionally starts with Azure Linux and will expand; other Microsoft products that ship kernels must be validated individually.
• Administrators should verify kernel version and kernel config on any Microsoft‑supplied Linux artifacts they run (including WSL2 custom kernels, Azure VM images, and AKS node images) and patch where necessary. If immediate patching is not feasible and the ATM/CLIP code exists as a loadable module, unloading/blacklisting the module is a practical temporary mitigation.
• The decisive question is not “which vendor wrote the advisory” but “does the specific kernel build in my environment include the vulnerable code and predate the fix?” Use the procedural checks above to make that determination.

Security teams and sysadmins should treat this CVE as part of routine kernel‑patch hygiene: validate your kernel images, prioritize patching where the ATM/CLIP subsystem is present, and monitor Microsoft’s CSAF/VEX updates for changes to product attestation as the VEX program expands.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center