CVE-2025-38181 CALIPSO Kernel Bug: Azure Linux Attestation and Cross Product Risk

CVE-2025-38181 is a kernel-level null-pointer dereference in the CALIPSO option handling that was fixed upstream by defensive checks in calipso_req_setattr() and calipso_req_delattr(); Microsoft’s Security Response Center (MSRC) has publicly attested that Azure Linux includes the implicated open-source code and is therefore potentially affected, but that attestation is product-scoped and not a technical guarantee that no other Microsoft product could contain the same vulnerable code.

Background / Overview​

CALIPSO (Common Architecture Label IPv6 Security Option) is an in-kernel option handling path used for network labeling and related features. The defect tracked as CVE-2025-38181 is a null-pointer dereference discovered by automated testing (syzkaller) that can occur during allocation of a CALIPSO option when a socket context expected by the CALIPSO code is absent under specific TCP SYN cookie handling conditions. The upstream kernel patch chooses to return an error in the SYN-cookie case rather than attempt unsafe dereferences or disable important protection logic.
Several independent vulnerability aggregators and major distribution vendors recorded the issue and published fixes or backports; public trackers list patched kernel versions across stable branches (for example, fixed commits were propagated to 5.4.x, 5.10.x, 5.15.x and recent 6.x stable trees). The National Vulnerability Database summarizes the technical root cause and rationale for the chosen fix.

---

The MSRC statement: what Microsoft actually said​

Microsoft’s public FAQ line on MSRC CVE pages for Linux/open-source component CVEs typically uses the phrasing:
“One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries with which the distro is composed. Microsoft is committed to transparency in this work which is why we began publishing CSAF/VEX in October 2025. If impact to additional products is identified, we will update the CVE to reflect this.”
That wording — and the short sentence that accompanies many MSRC Linux CVE entries — is an inventory attestation: Microsoft has inspected the Azure Linux distribution and found the implicated upstream component mapped to the CVE, so Azure Linux images are a confirmed remediation target.
Important nuance: MSRC’s attestation is product-scoped (Azure Linux) and not a global exclusivity guarantee. Large vendors commonly roll out machine-readable VEX/CSAF attestations product-by-product; an attestation that a particular product “includes” a component means Microsoft has completed its inventory checks for that product and is publishing the result. It does not automatically prove other Microsoft artifacts—WSL kernels, Marketplace images, container base images, partner appliances, or internal build outputs—do or do not include the same upstream code.

---

Short, direct answer to the user’s question​

• Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by CVE-2025-38181?

No — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the implicated CALIPSO code for CVE-2025-38181, and that makes Azure Linux the single confirmed Microsoft carrier at the time of the advisory. However, that attestation is deliberately scoped; it is not a technical proof that other Microsoft products cannot include the same vulnerable kernel code. Until Microsoft publishes additional VEX/CSAF attestations or updates the CVE mapping for other product artifacts, defenders should treat other Microsoft-distributed kernels and images as unverified rather than proven safe.

---

Why the distinction matters (technical and operational realities)​

Two separate facts are easily conflated when reading short vendor statements:

• Fact A — Attested presence: the vendor has examined Product X (here, Azure Linux) and found the vulnerable component; Product X is therefore in-scope for remediation and should be patched.
• Fact B — Product exclusivity: the inference that because the vendor named Product X it must be the only product affected.

Those are not equivalent. Large vendors ship many compiled artifacts, kernels, images and packages. The same upstream code can appear in multiple Microsoft artifacts depending on the exact kernel source tree, build time, kernel configuration (is the CALIPSO code compiled in or modular?), and any local backports or patches applied by the vendor or downstream distributor. For kernel-level CVEs like CVE-2025-38181, the true blast radius is an artifact-level question — whether a specific kernel binary contains the vulnerable commit or an upstream backport.
Operational implications:

• Treat Azure Linux images as Known Affected and apply Microsoft’s kernel/image updates first.
• For other Microsoft-provided artifacts (WSL kernels, curated Marketplace images, AKS node images, container base images published by Microsoft, partner appliances hosted via Microsoft channels), perform artifact-level verification until Microsoft publishes attestations for those products.

---

Technical recap of CVE-2025-38181 (concise, verifiable)​

• Vulnerability type: NULL pointer dereference (CWE-476) in CALIPSO option handling.
• Affected functions: calipso_req_setattr(), calipso_req_delattr() in net/ipv6/calipso.c.
• Root cause: under SYN-cookie processing (a change introduced by a TCP syncookies-related commit), the request-socket’s rsk_listener can be NULL; a subsequent code path used that pointer and could dereference it, leading to a kernel oops/crash.
• Impact: kernel panics / availability loss (local attack vector). Depending on system setup and attacker access, a local user or guest (in multi-tenant contexts) may be able to trigger an oops; the bug is availability-first rather than a direct remote code-execution vector.

Two authoritative trackers (NVD and OSV) document the same technical summary and list the upstream commit rationale and the chosen remediation (return an error in the SYN-cookie case). Distribution advisories also show backports to multiple stable trees.

---

Severity scores and vendor differences​

Different vendors and aggregators sometimes produce different CVSS scores and severity labels for the same underlying bug because they weigh exploitability and practical impact differently:

• NVD (National Vulnerability Database) reports a CVSS v3.1 base score around 5.5 for CVE-2025-38181, with the primary impact categorized as Availability and a Local attack vector.
• Some vendor product trackers (for example Amazon Linux/ALAS) mark the issue as Important and list a CVSS variant or distribution-specific vector leading to a higher numeric score (Amazon’s listing shows a CVSS v3 value of 7.0 in their product view). These vendor-specific scores reflect the packaged product’s particular configuration and threat model.

Practical takeaway: severity numbers differ but the operational fact is clear — kernel-level crashes on shared or production hosts are consequential and should be remediated promptly where the artifact is confirmed to include the vulnerable code.

---

Where this code might appear inside Microsoft’s ecosystem​

Technically, the vulnerable kernel code is part of upstream Linux sources. Any Microsoft artifact that ships a compiled Linux kernel built from a commit range predating the upstream fix — and that includes the CALIPSO codepath — could be a carrier. Examples to consider when inventorying Microsoft-supplied artifacts:

• Azure Linux images (attested by MSRC).
• WSL2 distributed kernels that Microsoft publishes or updates independently.
• Azure Marketplace VM images and curated VM images (especially where Microsoft or third-party publishers use similar base kernels).
• AKS node images or container host OS images if they are derived from Azure Linux/CBL-Mariner kernels.
• Container base images and CI build images published by Microsoft that include kernel header/tooling or package sets.
• Partner or third-party appliances distributed through Microsoft Marketplace (these are built by external publishers and can include arbitrary kernels).

Because Microsoft’s CSAF/VEX rollout started with Azure Linux and is phased, the presence of the code in other Microsoft artifacts should be considered possible until each artifact either receives a Not Affected attestation or you verify it yourself.

---

Practical, prioritized steps for system administrators and security teams​

Below are concrete, sequential actions you should take if you run Microsoft-supplied artifacts or operate systems where Microsoft images may be present.

• Prioritize Azure Linux remediation
• Pull Microsoft guidance and apply the kernel/image updates Microsoft published for Azure Linux images. Treat those images as "Known Affected" until Microsoft marks them otherwise.
• Inventory Microsoft-supplied artifacts in your environment
• Make a list of all Microsoft-distributed images and artifacts you run: Azure Marketplace images, container base images published by Microsoft, WSL distributions provided by Microsoft, AKS node images, and any appliances obtained via Microsoft channels. Use asset tags, image manifests, and orchestration platform metadata.
• Artifact-level verification (do this for each image or kernel binary)
• For running VMs/hosts: record kernel version and build metadata with uname -a and check kernel package versions from the distro (e.g., dpkg -l linux-image or rpm -qa kernel\).
• Where possible, extract kernel build identifiers and match them to upstream commit ranges; check whether the patched commit or later stable backports are present.
• For container images: scan images for included kernel-related packages or artifacts and confirm base OS package versions.
• For WSL or other Microsoft-shipped kernels: check the kernel binary version and any published SBOMs or VEX attestations.
• Use automated scanning and SBOMs
• Run image scanners and SBOM-based tooling to map CVE identifiers to artifacts. Configure scans to check kernel package versions and relevant distro advisory feeds. If you have reproducible builds, rebuild with patched kernels.
• Block or mitigate risky exposures
• If you cannot immediately patch a confirmed-affected kernel, consider limiting access to unprivileged users and guests who might trigger the CALIPSO path, and restrict network interfaces or features that expose CALIPSO handling.
• Consider applying IPS/host-based mitigations where applicable (e.g., disabling CALIPSO support if your environment does not rely on that functionality), but evaluate the operational impact before disabling kernel features.
• Track Microsoft VEX/CSAF attestations and MSRC updates
• Monitor MSRC product attestations for updates listing "Known Affected", "Not Affected", "Under Investigation", or "Fixed" for Microsoft products beyond Azure Linux. Microsoft has committed to expand these attestations over time.
• Document and communicate
• Update change control and incident response playbooks to reflect whether affected artifacts were found, the mitigation paths taken, and timelines for patch rollout.

---

How to verify whether an image contains the vulnerable CALIPSO code (technical checklist)​

• For Linux VM images:
• Run: uname -a to get the running kernel string.
• On Debian/Ubuntu: dpkg -l linux-image; on RHEL/Amazon Linux: rpm -qa kernel.
• Correlate the kernel package version with upstream fixed versions (check vendor advisories and stable-branch commits).
• If you can access the kernel build-id (readable via /proc/config.gz or the vmlinux build-id), map it against upstream commits.
• For container images:
• Inspect the image manifest and installed packages (use docker run --rm image cat /etc/os-release && package manager queries).
• If the image uses a Microsoft-published base, check Microsoft’s base image release notes and any published SBOM.
• For WSL or Microsoft-distributed kernels:
• Check the kernel version shipped with the WSL distro and cross-check with the MSRC attestation or distro security bulletins.
• When in doubt, treat the artifact as unverified and escalate to patching and rebuild workflows.

---

Risks and limitations of vendor attestations (critical analysis)​

Vendor attestations like MSRC’s VEX/CSAF outputs are a significant improvement in transparency and automation for enterprise vulnerability management. They reduce noise and provide clear signals for specific product families. Microsoft’s public commitment to publish VEX attestations beginning in October 2025 is a positive step and gives Azure Linux customers an authoritative change to act on.
However, there are limits you must treat as real operational constraints:

• Attestations are phased and product-scoped: coverage takes time, and the absence of an attestation for Product Y is not proof that Product Y is safe. Product teams and security operations must still perform artifact-level discovery.
• Large vendors produce many compiled artifacts daily; automated provenance and mapping across every binary is an engineering challenge. Expect gaps and delays.
• Kernel-level CVEs are highly artifact-specific: the presence of upstream files in a source tree is insufficient to determine exposure — you need to verify the compiled kernel binary and its configuration (is the vulnerable path compiled in?).

In short: Microsoft’s Azure Linux attestation is an authoritative signal for that product but it’s not a blanket safety certificate for Microsoft’s entire artifact footprint.

---

What we verified for this article​

To ground the statements above I cross-checked multiple independent authoritative sources:

• The NVD and OSV vulnerability records provide the canonical technical summary and the upstream rationale for the chosen fix. These sources describe the calipsoreq{set,del}attr() fix and the SYN-cookie interaction leading to the potential rsk_listener NULL.
• Distribution advisories and vendor trackers (Amazon Linux/ALAS, SUSE security updates, Debian trackers) list patched kernel packages and, in some cases, provide a product-specific severity label and remediation timeline; these corroborate the multi-branch upstream fix and show how downstream vendors mapped the fix.
• Microsoft’s MSRC update guide and public FAQ sentence (the attestation wording) are consistent across recent Linux-related CVE pages; Microsoft’s blog about the VEX/CSAF rollout explains the phased attestation approach that clarifies the intent behind single-product attestations.
• Independent analysis and reporting (security vendor feeds and community advisories) repeat the same technical facts, and several security vendors list the ranges of stable kernels that received backports.

Where public facts were not discoverable (for example, the presence of the CALIPSO code in a specific proprietary Microsoft internal appliance or a third-party Marketplace image you run), I flagged that as unverified and recommended artifact-level discovery.

---

Final assessment and recommended posture​

• Immediate: If you run Azure Linux images, prioritize Microsoft’s updates for that distro; treat that product as a confirmed remediation target.
• Short-to-medium term: Run an artifact-level inventory of all Microsoft-supplied images and kernels you operate (WSL kernels, Marketplace images, AKS/host images, container bases). If any artifact’s kernel predates the upstream fix and includes CALIPSO, schedule patching and rebuilds.
• Long term: Adopt SBOM and image-scan automation that ties vendor attestations (VEX/CSAF) to your asset inventory so that when Microsoft expands attestations beyond Azure Linux you can automatically reconcile which artifacts are covered and which require further verification.

Microsoft’s transparency steps are welcome and useful — Azure Linux is the product Microsoft has attested as including the vulnerable CALIPSO code for CVE-2025-38181 — but operational security requires you to verify the other Microsoft-supplied artifacts you run rather than assume they are unaffected.

---

CVE-2025-38181 is an availability-focused kernel defect with multi-vendor remediation already published; treat Azure Linux as in-scope per Microsoft’s attestation, patch it first, and then close the remaining blind spots by performing artifact-level verification across your Microsoft-supplied images and kernels until either Microsoft’s VEX/CSAF program or your own inventories prove them Not Affected.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center