The Linux kernel bug tracked as CVE-2025-38147 — described upstream as “calipso: Don't call calipso functions for AF_INET sk” — is a relatively compact but meaningful vulnerability whose real-world implications hinge less on dramatic remote code execution and more on software supply-chain and artifact‑management realities. Microsoft’s MSRC has publicly attested that Azure Linux (the Microsoft‑maintained distribution formerly known as CBL‑Mariner) includes the affected upstream component and is therefore a confirmed Microsoft product in scope; however, that attestation should not be read as a blanket guarantee that no other Microsoft product could include the same vulnerable code. This article explains what the bug is, why the Azure Linux VEX attestation matters, what it does — and does not — prove, and what administrators and security teams should do next to assess risk across Microsoft-supplied Linux artifacts.
CVE-2025-38147 was disclosed in early July 2025 (publicly recorded on July 3, 2025) and describes a null-pointer dereference in the kernel’s netlabel / CALIPSO code path. The bug results from a missing validation in a socket‑attribute routine that allows callers to pass an IPv6 address structure when the socket is actually an IPv4 socket; the mis‑matched address family can cause the kernel to dereference a NULL pointer when it assumes IPv6-only data structures exist. The immediate impact reported by multiple upstream trackers is a kernel crash (null‑ptr‑deref) — that is, a local or remotely triggered denial‑of‑service condition rather than an obvious privilege escalation or remote code execution primitive.
Microsoft’s security guidance for the CVE includes a short FAQ that says, in essence: Azure Linux has been confirmed as shipping the implicated upstream library; Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update the CVE listing if more Microsoft products are later found to ship the same component. That single‑product attestation is accurate and useful for Azure Linux consumers, but it requires careful interpretation when applied to other Microsoft artifacts.
That wording is intentionally scoped: it is an authoritative, product‑level confirmation for Azure Linux, but it is not a universal declaration about every Microsoft artifact. The distinction between “confirmed for Azure Linux” and “exhaustively scanned across all Microsoft products” is the single most important operational takeaway for defenders.
Why that matters:
For security teams, the right posture is practical and process-driven: accept the MSRC attestation as authoritative for the named product, but assume unknowns until you verify them for any other Microsoft-supplied artifacts. Use kernel versioning, kernel configuration, and vendor patch notes to map exposure precisely; where you cannot verify exposure quickly, apply least‑privilege network controls and isolate the affected hosts until you can patch or confirm safety.
Microsoft’s move to publish CSAF/VEX attestations (the program began in October 2025) is an important step toward the transparency defenders need. But until every product and artifact is inventoried and attested, operational risk remains at the artifact level. Treat Azure Linux as a confirmed “yes,” treat other Microsoft artifacts as “unknown until proven otherwise,” and use YOUR asset inventory, SBOMs, and image validation processes to close the gap.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE-2025-38147 was disclosed in early July 2025 (publicly recorded on July 3, 2025) and describes a null-pointer dereference in the kernel’s netlabel / CALIPSO code path. The bug results from a missing validation in a socket‑attribute routine that allows callers to pass an IPv6 address structure when the socket is actually an IPv4 socket; the mis‑matched address family can cause the kernel to dereference a NULL pointer when it assumes IPv6-only data structures exist. The immediate impact reported by multiple upstream trackers is a kernel crash (null‑ptr‑deref) — that is, a local or remotely triggered denial‑of‑service condition rather than an obvious privilege escalation or remote code execution primitive.Microsoft’s security guidance for the CVE includes a short FAQ that says, in essence: Azure Linux has been confirmed as shipping the implicated upstream library; Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update the CVE listing if more Microsoft products are later found to ship the same component. That single‑product attestation is accurate and useful for Azure Linux consumers, but it requires careful interpretation when applied to other Microsoft artifacts.
What the vulnerability actually is — technical snapshot
The component: netlabel and CALIPSO
- CALIPSO (Common Architecture Label IPv6 Security Option) and the Linux netlabel framework are kernel subsystems used for network labeling / security labeling integration with Linux LSMs (like SELinux) and for processing IP options tied to sensitivity labels.
- The offending code path sits in the kernel’s netlabel/ CALIPSO plumbing, where userland requests that interact with socket address information are validated and applied.
The bug in plain terms
- A kernel function that handles a connection attribute change branches on the struct sockaddr.sa_family value supplied by userspace.
- The code does not robustly verify that the supplied address family matches the actual type of the socket object (the socket’s AF_INET vs AF_INET6 state).
- When an IPv6 sockaddr is passed to a handler operating on an IPv4 socket, the code can follow the IPv6-specific path and dereference IPv6-only fields that are NULL for an IPv4 socket.
- The consequence observed in reported traces is a NULL-pointer dereference in IPv6 option handling, resulting in an OOPS and kernel crash.
Why this matters operationally
- The bug is not a straightforward remote code execution chain by itself; the primary impact is availability (kernel crash) and potentially system instability.
- Certain configurations, kernel versions, and feature sets (for example, whether CALIPSO is compiled in, or netlabel is enabled) determine whether a particular kernel artifact is actually vulnerable.
- Exploitability depends heavily on the presence of the code paths in the compiled kernel and on the local attack surface (exposed syscalls, services, container boundaries).
Who is confirmed affected — and what Microsoft said
Microsoft’s public attestation model for third‑party CVEs began moving into machine‑readable VEX/CSAF disclosures in October 2025, and MSRC has used that mechanism to publish product‑level inventory statements. For CVE‑2025‑38147 the MSRC entry expressly confirms Azure Linux as a product that includes the implicated upstream code and therefore a confirmed affected Microsoft product for this CVE. Microsoft’s statement also says that the company will update the CVE/VEX if additional Microsoft products are identified as shipping the same upstream component.That wording is intentionally scoped: it is an authoritative, product‑level confirmation for Azure Linux, but it is not a universal declaration about every Microsoft artifact. The distinction between “confirmed for Azure Linux” and “exhaustively scanned across all Microsoft products” is the single most important operational takeaway for defenders.
Is Azure Linux the only Microsoft product that could be affected?
Short answer: No — not necessarily. Long answer: Azure Linux is the only Microsoft product Microsoft has publically attested so far to include the upstream code at the time of the advisory, but Microsoft ships multiple Linux‑related artifacts and kernels with different versions, configurations, and backports. Any one of those artifacts could include the same netlabel/CALIPSO sources depending on kernel version and build options.Why that matters:
- Microsoft produces multiple kernel artifacts and Linux‑based images that are functionally distinct:
- Azure Linux (explicitly attested).
- WSL2 kernel builds shipped with Windows (these kernels are maintained and updated by Microsoft and are now an open‑source project; whether they contain a given upstream file depends on the kernel version and CONFIG flags).
- Azure guest images and curated Marketplace images where a vendor kernel (or linux‑azure) might be used.
- AKS node images, container base images, appliance kernels, and other internal or partner‑produced images that Microsoft distributes or supports.
- Whether an artifact is vulnerable comes down to three technical factors:
- Kernel version / commit range — does the compiled kernel include the upstream commits that contained the bug?
- Build configuration (CONFIG_ options) — is CALIPSO/netlabel built into that kernel or configured as a module?
- Backports and vendor patches — did Microsoft or a downstream vendor backport a fix or intentionally disable the subsystem?
The limits of VEX/CSAF attestations — what they prove, and what they don’t
Microsoft’s CSAF/VEX approach provides machine‑readable, product‑level attestations stating whether a named product is “Known Affected”, “Under Investigation”, “Not Affected”, or “Fixed.” This is a huge step forward for operational clarity, but there are vital limitations to keep in mind:- A VEX attestation is product‑scoped, not universal. It reports the state of a named product artifact (for example, “Azure Linux distribution image set A”). It does not automatically speak for every kernel image Microsoft ever shipped.
- Attestation is an inventory snapshot. It reflects the state of Microsoft’s inspection at a point in time and for a defined artifact set. Microsoft’s rollout started with Azure Linux as a manageable first scope and will expand over time.
- Absence of an attestation for a product is not evidence that the product is clean. It is evidence that Microsoft has not yet published the product’s VEX statement.
- Per‑artifact configuration differences mean that two Microsoft kernels built and released at the same time can include different sets of features and therefore have different vulnerability exposure.
- VEX improves automation and reduces false positives, but organizations still need to validate deployed images and patch inventories in their own environments.
Practical risk assessment for Microsoft customers
If you run Microsoft‑supplied Linux artifacts, here’s how to think about risk and prioritize work.- For Azure Linux customers: treat the MSRC attestation as an authoritative “yes” — you should apply the vendor‑supplied kernel updates or follow the mitigation guidance Microsoft publishes for that distro immediately.
- For WSL2 users: do not assume WSL2 is safe simply because MSRC only mentioned Azure Linux. WSL2 uses a Microsoft‑maintained kernel that is updated via Windows Update; whether a specific WSL kernel release contains the vulnerable CALIPSO code depends on the kernel version and the selected branch. Operators should:
- Confirm the kernel version WSL2 is using on each host.
- Cross‑reference that version against upstream fixes or vendor advisories.
- Apply WSL/Windows updates if Microsoft announces a WSL kernel patch.
- For Azure VM and Marketplace images: treat images as separate artifacts. Image maintainers (Microsoft and Marketplace publishers) may use different kernel builds. Administrators should:
- Inspect the kernel version and configuration inside images they run.
- Ensure image patching policies are current and that images are reprovisioned with patched kernels where necessary.
- For AKS, container nodes, and managed services: the platform provider (Azure) controls underlying node images. Confirm platform‑level advisories (AKS node pool patch window guidance) and apply recommended upgrades.
- For organizations with hybrid inventories: perform per‑artifact checks using your standard asset‑inventory and SBOM processes. Don’t rely on a single vendor attestation to cover everything you run.
Detection and mitigation — what to do now
If you are responsible for Linux workloads on Microsoft platforms, follow this prioritized checklist.1. Inventory and triage (first 24–72 hours)
- Enumerate all Linux kernel artifacts you run that are Microsoft‑supplied or Microsoft‑maintained: Azure Linux images, WSL2 kernels, linux‑azure kernels, AKS node images, Marketplace images, and any Windows hosts running WSL2.
- Record the exact kernel version numbers and build identifiers from each host (uname -a and /proc/version for Linux artifacts; WSL2 kernel versions can be viewed inside each WSL instance).
- Identify which artifacts expose network services or accept untrusted socket operations; these are higher‑priority for triage.
2. Map versions to the fix window
- Compare your kernel versions against published upstream fix commits and vendor advisories for CVE‑2025‑38147. If your kernel version is newer than the patched range (or includes the upstream fix), you are lower risk.
- If you are using Azure Linux, apply MSRC/azure‑linux updates immediately per the vendor’s guidance.
3. Patch and configuration mitigations
- Where a vendor patch or updated kernel package is available: schedule and apply the updates per your change window.
- Where a patch is not yet available or an artifact cannot be quickly updated:
- Consider workload isolation and network rules to limit the ability of untrusted principals to reach and exercise the vulnerable syscall paths.
- Evaluate disabling netlabel/CALIPSO at boot or blacklisting the module if your environment does not require it. (Be careful: do this only after validating dependencies; removing kernel features may affect LSM integrations such as SELinux or third‑party labeling.)
- For WSL2, apply Windows updates that contain WSL kernel updates when Microsoft publishes them; as a temporary measure, avoid exposing WSL instances to untrusted networks.
4. Detection and monitoring
- Look for kernel oopses and crashes tied to netlabel/CALIPSO stack traces. The reported fault signatures contain function names like calipso_sock_setattr() and netlbl_conn_setattr() and will show in dmesg or system logs.
- Monitor for unusual OOMs/ reboots and correlate with socket/connect syscalls from untrusted processes.
- In cloud environments, use guest‑level telemetry (boot diagnostics, serial logs) and platform‑level monitoring to detect node-level restarts or kernel OOPS.
5. Post‑remediation validation
- After patching, validate the absence of the vulnerable behavior by ensuring the new kernel version contains the upstream fixes.
- Reconfirm that services and LSM policies operate as expected; test any changes to netlabel or CALIPSO configuration in a staging environment before wide rollout.
How to confirm whether a Microsoft artifact is affected (practical guidance)
- Determine kernel version: run uname -r or check kernel release metadata inside the artifact.
- Inspect kernel configuration: look for CONFIG_NETLABEL or CALIPSO-related config flags; if the subsystem is disabled, the binary may not be exposed.
- If possible, inspect the binary compile options or vendor release notes for backports that map to the upstream fixes.
- Cross‑reference kernel commit ranges against upstream fix commits for CVE‑2025‑38147.
- For WSL2 and other Microsoft‑maintained kernels, watch Microsoft update channels and the WSL kernel repo for explicit fix commits or Windows Update KBs that mention a WSL kernel update.
Strengths and risks of Microsoft’s approach (analysis)
Strengths
- Machine‑readable attestations (VEX/CSAF) are a major operational improvement. They let security automation ingest vendor inventory statements and reduce noisy alerts where the vendor can confidently report “Not affected.”
- Starting with Azure Linux makes operational sense: it is a single, Microsoft‑owned distro designed for cloud images, and it is an efficient pilot to validate the VEX pipeline.
- Transparency commitment (CSAF + VEX) helps customers make faster, more accurate remediation decisions and reduces vendor blind spots in the supply chain.
Risks and gaps
- Phased rollout causes “unknowns”: until Microsoft publishes VEX for every product family (WSL2, AKS, Marketplace images, etc.), customers must perform their own artifact validation — which adds operational overhead.
- Per‑artifact variability: Microsoft ships multiple kernel artifacts with differing CONFIG flags. A single attestation does not necessarily translate to all kernels Microsoft ships, making blanket assumptions dangerous.
- Reliance on vendor updates alone is insufficient: many organizations rely on vendor attestations, but software supply chains are complex; defenders need local inventory and image validation to close the loop.
Recommendations — concise action list
- Treat the MSRC attestation as authoritative for Azure Linux — apply patches or updates Microsoft publishes for that distro without delay.
- For every other Microsoft‑supplied Linux artifact you run (WSL2, Azure images, AKS nodes, Marketplace VMs), perform per‑artifact validation:
- Collect kernel version and config.
- Map versions to upstream fixes or vendor advisories.
- If uncertain, apply compensating controls (isolate, restrict access to the affected hosts).
- Update detection rules to look for kernel OOPS signatures referencing calipso/netlabel function names and monitor for correlated reboots.
- Automate the ingestion of vendor CSAF/VEX data where possible, but use it to augment — not replace — your own image inventory and SBOM checks.
- Document your artifact provenance and build configuration as part of standard image hardening; that documentation is the fastest route to proving whether a given image is affected.
Final assessment and conclusion
CVE‑2025‑38147 is a classic example of a vulnerability whose technical severity (kernel crash via NULL dereference) is less consequential than the operational complexity it exposes in modern software supply chains. Microsoft’s public attestation that Azure Linux includes the implicated upstream component is a clear, actionable data point — Azure Linux customers should treat it as confirmed and remediate accordingly. Crucially, that attestation is product‑scoped; it does not guarantee that other Microsoft artifacts (WSL2 kernels, Azure guest images, Marketplace VM images, AKS node kernels) are free from the same upstream code.For security teams, the right posture is practical and process-driven: accept the MSRC attestation as authoritative for the named product, but assume unknowns until you verify them for any other Microsoft-supplied artifacts. Use kernel versioning, kernel configuration, and vendor patch notes to map exposure precisely; where you cannot verify exposure quickly, apply least‑privilege network controls and isolate the affected hosts until you can patch or confirm safety.
Microsoft’s move to publish CSAF/VEX attestations (the program began in October 2025) is an important step toward the transparency defenders need. But until every product and artifact is inventoried and attested, operational risk remains at the artifact level. Treat Azure Linux as a confirmed “yes,” treat other Microsoft artifacts as “unknown until proven otherwise,” and use YOUR asset inventory, SBOMs, and image validation processes to close the gap.
Source: MSRC Security Update Guide - Microsoft Security Response Center
