Microsoft’s advisory on CVE-2025-38112 confirms a race condition in the Linux kernel networking code — a time-of-check to time-of-use (TOCTOU) flaw in sk_is_readable() that can result in a null-pointer dereference — and while Microsoft has publicly attested this vulnerability for its Azure Linux distribution, the technical reality is broader: any Microsoft product that ships a Linux kernel binary or kernel modules built from the affected upstream commits could, in principle, include the vulnerable code until it is patched.
The CVE describes a subtle race in the kernel’s socket handling: sk->sk_prot->sock_is_readable is checked and assumed valid, but under certain sockmap lifecycle operations sk->sk_prot can be restored to a state where its sock_is_readable pointer is NULL. If that pointer becomes NULL between the check and subsequent use, the kernel can dereference a NULL pointer and crash, producing a denial-of-service condition for the affected host. This problem was introduced in a series of upstream commits and fixed in later stable releases by ensuring the function pointer cannot become NULL after the check.
The vulnerability was publicly tracked as CVE-2025-38112 and received a medium-to-high severity characterization in several ecosystem advisories; most maintainers urged updating to the patched stable kernel releases rather than cherry-picking single commits, because the kernel community tests fixes as part of whole releases.
It is important to parse that carefully. An attestation (via CSAF/VEX or similar machine-readable inventory) tells defenders, with high confidence, which specific Microsoft product artifacts include a given upstream component. But a lack of attestation is not the same as a technical guarantee that other Microsoft artifacts are safe. Microsoft distributes multiple kernel artifacts — including kernel images that power Azure VM images and the Windows Subsystem for Linux (WSL2) kernel builds — and many of those artifacts are built from upstream kernel trees and may include the same source files or modules. Whether any one of those artifacts is vulnerable is a product-by-product question that depends on the kernel version, the exact upstream commit range, and the kernel configuration used at build time.
Key examples where Microsoft ships Linux kernel binaries or modules:
However, VEX is an attestation mechanism tied to a named product/artifact. Microsoft distributes multiple Linux-related artifacts across its product portfolio. Each artifact is a separate build and must be attested individually. Thus, while VEX reduces ambiguity for attested artifacts, defenders and operators must still:
Where Microsoft is explicit — the Azure Linux attestation — that is accepted as authoritative for that specific product. Where Microsoft is silent, independent artifact inspection (and correlation against the kernel commit list) is the reliable path to verification. If an organization needs absolute assurance that a Microsoft-provided artifact is not affected, it should request or await a Microsoft VEX/CSAF attestation covering that specific artifact or perform the binary/source check itself.
Action checklist (short):
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
The CVE describes a subtle race in the kernel’s socket handling: sk->sk_prot->sock_is_readable is checked and assumed valid, but under certain sockmap lifecycle operations sk->sk_prot can be restored to a state where its sock_is_readable pointer is NULL. If that pointer becomes NULL between the check and subsequent use, the kernel can dereference a NULL pointer and crash, producing a denial-of-service condition for the affected host. This problem was introduced in a series of upstream commits and fixed in later stable releases by ensuring the function pointer cannot become NULL after the check.The vulnerability was publicly tracked as CVE-2025-38112 and received a medium-to-high severity characterization in several ecosystem advisories; most maintainers urged updating to the patched stable kernel releases rather than cherry-picking single commits, because the kernel community tests fixes as part of whole releases.
What Microsoft said — and what that statement actually means
Microsoft’s public FAQ entry for the advisory answers the question “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected?” with a practical — and intentionally narrow — answer: Microsoft has attested that Azure Linux includes the implicated upstream code and will publish CSAF/VEX attestations; if additional Microsoft products are impacted they will be added to the CVE entry. That response is a transparency and scope statement: it confirms Azure Linux as an attested, confirmed hit while leaving open the possibility of further impact.It is important to parse that carefully. An attestation (via CSAF/VEX or similar machine-readable inventory) tells defenders, with high confidence, which specific Microsoft product artifacts include a given upstream component. But a lack of attestation is not the same as a technical guarantee that other Microsoft artifacts are safe. Microsoft distributes multiple kernel artifacts — including kernel images that power Azure VM images and the Windows Subsystem for Linux (WSL2) kernel builds — and many of those artifacts are built from upstream kernel trees and may include the same source files or modules. Whether any one of those artifacts is vulnerable is a product-by-product question that depends on the kernel version, the exact upstream commit range, and the kernel configuration used at build time.
Technical anatomy: what the bug is, how it happens, and why it matters
The code path and the race
- The vulnerability centers on the sk_is_readable() helper and the sk->sk_prot->sock_is_readable function pointer.
- When a socket is managed inside a sockmap or has its lifecycle altered (notably during sk_psock_put() and related operations), sk->sk_prot can be restored to a different value. That restored value may have a NULL sock_is_readable pointer.
- If the kernel checks the pointer (time-of-check) and proceeds to use it (time-of-use) after sk->sk_prot has been changed, the kernel can dereference NULL, producing memory access faults and potential kernel panics or OOPS.
Severity and exploitability
- The main impact is denial of service (system crash) through a locally-triggered race. The attack requires the ability to manipulate socket lifecycles — typically a local operation, which lowers remote exploitability but elevates operational risk for multi-tenant hosts and shared infrastructure where unprivileged users may be able to exercise such operations.
- Public advisories and vendor trackers assigned medium-to-high scores and recommended patching. The kernel team listed the specific fixes and the commit ranges where the issue was introduced and corrected.
Which kernel versions are affected
- The upstream announcements and distribution advisories list affected kernel version ranges and the commits that remediate the issue. Distributions backported fixes into several kernel release series; maintainers advised updating to the latest stable kernel in those series or applying the listed stable commits.
Are other Microsoft products likely to be affected?
Short answer: Yes, possibly — but not necessarily. Microsoft’s public attestation names Azure Linux; other Microsoft-distributed kernel artifacts certainly exist and have historically tracked upstream kernel releases. From a technical perspective, anything Microsoft ships that contains a Linux kernel binary or kernel modules built from the vulnerable commit ranges could be affected until patched.Key examples where Microsoft ships Linux kernel binaries or modules:
- Azure Linux (attested by Microsoft) — Microsoft has confirmed this distribution includes the implicated upstream source and published VEX/CSAF information for it. That makes Azure Linux a confirmed point of impact under Microsoft’s current disclosure.
- WSL2 kernel builds — Microsoft publishes its WSL2 kernel source tree and binary releases. WSL2 kernels are derived from upstream kernel branches and historically moved between long-term support releases (5.15 → 6.6, etc.). The WSL2 kernel repositories and tags show Microsoft’s own kernel artifacts that could include the same upstream components, depending on version and configuration. Whether a given WSL2 kernel release contains the vulnerable code is a matter of comparing its version/commits to the upstream affected range.
- linux-azure kernel packages and Azure Marketplace images — Microsoft, in coordination with distro maintainers, also produces kernel packages tailored for Azure (for example linux-azure kernels used in official images). Those packages can be updated by distro vendors but are distributed inside Azure VM images. The presence or absence of a particular vulnerable function depends on which upstream kernel version and config were used when the package was built.
How defenders should triage this — a practical checklist
Follow these steps in sequence to determine exposure and remediate:- Inventory: Identify Microsoft-supplied Linux kernel artifacts in your environment.
- Check Azure VM images that use Microsoft-curated kernels (Azure Linux, linux-azure packages).
- Check hosts running WSL2 (the kernel used by WSL is updated by Microsoft Update or can be custom-specified). Determine the kernel version reported by the WSL2 instance.
- Compare versions/commits: Map the running kernel version or the packaged kernel build to the upstream affected ranges and the listed fixing commits. If the kernel version is earlier than the patched releases or the commit list, treat it as potentially vulnerable. The kernel CVE announcement supplies the commit IDs and affected file(s).
- Patch or update:
- For Azure Linux, install the vendor-provided security update from Microsoft (or the distro channel managed by Microsoft) and reboot as required.
- For WSL2 instances, ensure Windows Update has delivered the latest WSL kernel package or, for custom kernels, rebuild/redeploy with a fixed upstream base that contains the relevant fixes. Microsoft’s WSL kernel is serviced through the platform’s update mechanism, and custom kernels must be rebuilt against upstream patches.
- For unmanaged or third-party images (AKS node images, Marketplace images): If you cannot rely on an attestation for the artifact, extract the kernel version or binary and compare it against the upstream commit list. If in doubt, deploy a patched kernel image or rebuild images with the fixed kernel.
- Mitigation interim measures: Where immediate patching is impossible, apply host-level mitigations:
- Restrict unprivileged users from running tools or services that can manipulate sockmaps or perform operations likely to trigger the race.
- Isolate multi-tenant workloads in stronger sandboxing/VM boundaries so a local kernel crash affects fewer tenants.
- Monitor for OOPS, kernel panic logs, and unusual crashes in network stacks; these may indicate exploitation attempts or triggering of the race condition.
Why Microsoft’s attestation model is useful — and why it doesn’t remove the need for artifact inspection
Microsoft’s CSAF/VEX commitments are an important step toward transparent software inventory and automated vulnerability triage. When Microsoft publishes a VEX statement for a product (for example, Azure Linux), customers can programmatically mark specific product artifacts as affected or not — dramatically reducing the noise in triage workflows. Microsoft’s FAQ explicitly highlights Azure Linux and points to the CSAF/VEX initiative as the channel for transparency.However, VEX is an attestation mechanism tied to a named product/artifact. Microsoft distributes multiple Linux-related artifacts across its product portfolio. Each artifact is a separate build and must be attested individually. Thus, while VEX reduces ambiguity for attested artifacts, defenders and operators must still:
- Verify the kernel versions in every artifact they run (WSL2 instances, Azure VM images, Marketplace images, AKS node pools).
- Recognize that a lack of attestation does not equal proof of absence — it simply indicates Microsoft has not yet published a machine-readable inventory statement for that artifact regarding this CVE. Independent inspection and version mapping remain essential for comprehensive risk management.
Cross-checks and independent verification
The kernel community’s CVE announcement lists the precise commits that introduced and fixed the bug; distribution advisories (Debian, Ubuntu, Red Hat, Amazon Linux OS advisories) independently tracked the CVE and the patch rollouts, and security trackers published the same technical description and remediation guidance. These independent sources agree on the nature of the flaw (a TOCTOU leading to a possible null dereference), the mitigation (upgrade to patched kernel releases or apply the fix commits), and the operational impact (denial of service via kernel crash). This multi-source convergence strengthens confidence in the technical characterization and the urgent need to patch.Where Microsoft is explicit — the Azure Linux attestation — that is accepted as authoritative for that specific product. Where Microsoft is silent, independent artifact inspection (and correlation against the kernel commit list) is the reliable path to verification. If an organization needs absolute assurance that a Microsoft-provided artifact is not affected, it should request or await a Microsoft VEX/CSAF attestation covering that specific artifact or perform the binary/source check itself.
Risk analysis: who should be most worried?
- Cloud tenants on multi-tenant Azure hosts: If a cloud image or kernel used by tenant workloads is vulnerable, a local user could trigger a kernel panic; on shared hypervisor infrastructure this could materially affect availability for other tenants. Azure’s use of dedicated kernel variants and image maintenance reduces but does not eliminate risk without explicit attestation.
- Enterprises running WSL2 at scale: Developer machines running WSL2 are less likely to be targeted for remote exploitation, but organizations that rely on WSL2 for CI/CD or build hosts should ensure their WSL kernels are current; Microsoft services WSL kernels through Windows Update.
- Operators of container platforms and Kubernetes clusters: Node images and underlying kernel versions determine exposure. A vulnerable node kernel in a cluster can be crashed by a malicious or buggy workload that manipulates socket constructs.
Recommendations for Microsoft and for customers
For Microsoft (recommended as constructive criticism)
- Continue accelerating CSAF/VEX coverage across all kernel-bearing artifacts: WSL2 kernels, linux-azure packages, Azure Marketplace images, AKS node images, and any other Microsoft-distributed kernel binaries.
- When possible, publish artifact-level attestations with build-time metadata (kernel config, build tag, upstream commit range) so downstream operators can automate triage.
- Provide clear guidance for WSL2 users about how and when WSL kernel updates are delivered, and steps to force an update for environments where Windows Update is centrally controlled.
For customers and operators
- Assume Azure Linux images are affected unless you have applied the vendor update. For other Microsoft artifacts, do not assume safety purely because Microsoft has not yet attested them — perform version and commit comparisons where feasible.
- Patch promptly: apply vendor kernel updates or rebuild images against patched upstream kernels. Reboot hosts as required to make fixes take effect.
- Harden multi-tenant environments: reduce unprivileged capabilities that permit manipulation of socket internals, and apply network-level and process-level isolation for untrusted workloads.
- Automate inventory: adopt software bill-of-materials (SBOM), CSAF/VEX ingestion, and binary-to-commit comparison tooling so you can quickly determine exposure when new CVEs are released.
What we still do not know — and why that uncertainty matters
Microsoft’s advisory leaves open the timeline and scope for attestations beyond Azure Linux. Until Microsoft publishes VEX entries for other artifacts or until operators inspect individual artifacts, it is technically impossible to say categorically that only Azure Linux is affected. Practical uncertainty persists in several areas:- Which specific WSL2 kernel tags or Windows update bundles (if any) contained affected upstream commits at the time of release?
- Which Azure Marketplace images or linux-azure package versions included the vulnerable code before downstream vendors or Microsoft applied fixes?
- Have all downstream vendors that repackage Microsoft-distributed kernels applied the fix to their published images?
Conclusion
CVE-2025-38112 is a classic kernel TOCTOU: a fragile function-pointer check in the socket layer that can be invalidated by concurrent socket lifecycle operations, producing null-pointer dereferences and potential denial-of-service. Microsoft has publicly attested Azure Linux as an affected product and signaled it will publish CSAF/VEX attestations; that attestation is valuable but limited in scope. From a technical vantage point, any Microsoft product that ships a Linux kernel build or kernel modules derived from the affected upstream commit range could be affected until patched. Operators must therefore combine Microsoft attestations, independent artifact inspection, and an aggressive patch-and-reboot posture to eliminate exposure.Action checklist (short):
- Inventory Microsoft-supplied kernel artifacts in your environment.
- Map running kernel versions to the upstream fix commits.
- Patch or update Azure Linux instances immediately; verify WSL2 and Azure image kernels are patched or rebuild images.
- Apply containment and monitoring for hosts that cannot be patched immediately.
Source: MSRC Security Update Guide - Microsoft Security Response Center
