CVE-2025-39745 RCU Splat in PREEMPT_RT Kernels and Azure Linux Attestations

The Linux kernel change tracked as CVE-2025-39745 fixes a spurious “splat” in the RCU torture test harness when kernels are built with the PREEMPT_RT real‑time configuration; Microsoft’s short public notice that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate for the Azure Linux images Microsoft has inventory‑checked, but it is not a technical guarantee that no other Microsoft product could include the same upstream code.

Background / Overview​

The vulnerability labelled CVE‑2025‑39745 arises from a correctness issue inside the kernel’s RCU (Read‑Copy‑Update) torture test code (rcutorture). When kernels are compiled with CONFIG_PREEMPT_RT=y — the configuration that enables preemptive real‑time behavior — exercising rcutorture can produce a kernel warning (a “splat”) originating in rcutorture_one_extend_check(). That warning is symptomatic of inconsistent bookkeeping around softirqs/BH (bottom halves) in RT builds and leads to test failures and potential instability for real‑time workloads under test. The issue was reported and fixed upstream in September 2025; multiple vulnerability databases and distributor advisories catalog the problem and link to the kernel patches.
Why this matters operationally: rcutorture itself is a kernel test tool used to stress RCU invariants. The practical blast radius depends on whether a given kernel binary actually includes the rcutorture test code and whether it was built with PREEMPT_RT enabled. Many production kernels do not include rcutorture, and many kernels are not RT‑configured. But where both conditions are true — for example specialized real‑time images used for deterministic workloads — the splat can indicate instability or crash risk during test runs or in extreme cases when test code is present in shipped artifacts. Several vendor trackers, including NVD and distro advisories, list affected kernel version ranges and note that the fix is to update to patched kernel builds.

---

What Microsoft actually said — and what that phrase means​

Microsoft’s brief advisory language — “Azure Linux includes this open‑source library and is therefore potentially affected” — performs two practical functions at once. First, it gives Azure Linux customers a clear, authoritative signal: Microsoft’s inventory work has confirmed the component appears in the Azure Linux artifacts they ship, so those customers should treat the VEX/CSAF attestation as a definitive “in scope” signal for that product family. Second, the wording is deliberately scoped: it is an authoritative inventory statement for Azure Linux only, not an explicit statement that no other Microsoft product contains the same upstream code. Microsoft has also committed to publish machine‑readable VEX/CSAF attestations (starting with Azure Linux in October 2025) and to update CVE mappings if additional products are found to ship the component.
Put bluntly: Microsoft’s public position is operationally precise — Azure Linux is a confirmed carrier of the implicated upstream component and therefore must be prioritized for patching — but that position is not the same as claimininside Microsoft. Absence of an attestation for other Microsoft artifacts is an absence of attestation, not definitive proof of absence of the vulnerable code. That nuance is the single most consequential point defenders must understand when reading the MSRC wording.

---

Why Azure Linux might be singled out — and why that doesn’t imply exclusivity​

There are practical reasons Microsoft started its VEX/CSAF rollout with Azure Linux and why the initial attestation names that product family first.

• Azure Linux (formerly CBL‑Mariner) is a focused Microsoft‑maintained Linux distribution used to build and run many cloud images and tools. Starting VEX work with a single product family simplifies inventory and validates the VEX pipeline.
• A product‑scoped inventory (per product family) is easier to automate and verify than an exhaustive scan across dozens of disparate artifacts, kernels, marketplace images, and embedded builds.
• The VEX/CSAF model is intentionally phased: Microsoft will extend attestations to additional products over time and will update CVE records if more artifacts are discovered to ship the vulnerable code.

That operational pragmatism, however, does not mean Azure Linux is the only Micould ever include the rcutorture code. Microsoft produces and distributes multiple Linux‑adjacent artifacts — WSL2 kernels, linux‑azure kernel builds, AKS/VM node images, Marketplace images, appliance images for partners, and container host kernels used in managed services — any of which might, depending on kernel version and build configuration, carry the same upstream source and therefore be exposed. The determining factors are artifact provenance, kernel version ranges, and build-time CONFIG_* flags that decide which subsystems and test code are compiled into the image.

---

Technical scope: who exactly is affected?​

Two questions determine exposure:

• Does the artifact contain the upstream rcutorture code (the test harness and associated kernel source)?
• Was the kernel built with CONFIG_PREEMPT_RT=y (real‑time preemption)?

If the answer to both is yes, the artifact should be treated as potentially affected until patched. Vulnerability trackers list the affected upstream version ranges; for CVE‑2025‑39745 the NVD entry and vendor advisories indicate the issue touched certain 6.15/6.16 upstream windows and was addressed by targeted patches in the stable trees. Distributors (for example Amazon Linux, Red Hat, and others) have published advisories mapping the CVE against their kernel packages and listing pending fixes or versions that resolve the issue. Microsoft’s Azure Linux attestation confirms Azure Linux carries the component in the inventory it completed.
Operationally, the highest‑priority populations are:

• Dedicated RT images used in real‑time workloads where PREEMPT_RT is enabled.
• Any kernel builds or appliance images that intentionally include kernel test harnesses or debug/test modules.
• Test VMs and CI runners that execute kernel torture suites inside production‑like environments.
• Supply‑chain artifacts that reuse upstream kernel sources without stripping test code.

For general purpose server images that do not have PREEMPT_RT enabled and do not include test harness code, the practical risk is much lower. That said, attackers and defenders alike should avoid assuming absence without verification.

---

Strengths of Microsoft’s approach — transparency and machine‑readability​

Microsoft’s recent commitment to machine‑readable CSAF and VEX attestations is a material win for defenders:

• Faster automation: VEX provides deterministic attestations that automated scanners can consume, reducing time spent triaging false positives.
• Clear product scope: By declaring a product as “Known Affected,” “Not Affected,” “Under Investigation,” or “Fixed,” Microsoft gives operators a direct action signal they can program into pipelines.
• Accountaby: VEX/CSAF entries are auditable artifacts; Microsoft’s pledge to update them as inventory work expands creates an explicit process for change.
• Industry alignment: Publishing machine‑readable data is aligned with evolving industry practices that help national teams, vendors, and enterprise SOCs automate responses to upstream open‑source issues.

These are genuine operational improvements compared with terse prose advisories that force human interpretation at scale.

---

Risks and gaps to watch for​

Transparency helps, but several practical risks remain:

• Attestation scope vs. artifact scope: A VEX file for Azure Linux does not automatically cover other Microsoft artifacts. Administrators who assume otherwise risk blind spots in their inventories.
• Build‑time divergence: Two kernels built from the same upstream base can diverge substantially via different CONFIG_* flags or backports. Code present in one build might be absent in another, even inside the same vendor. This makes per‑artifact verification essential.
• Hidden test code in distributed kernels: Some vendors ship kernels that still carry test modules or development helpers, especially in images intended for debugging or testing; those carriers extend attack surface in ways automated scanners may miss.
• Patch cadence mismatch: Different Microsoft teams maintain different artifacts with different release cadences. Azure Linux images might be patched quickly following a VEX attestation; other artifacts (WSL kernels, Marketplace images) may take longer to inventory and patch.
• Overreliance on third‑party trackers: Generic vulnerability feeds will list the CVE and patch links, but defenders must map those to their specific artifacts — the semantic gap between “upstream fix exists” and “my image is safe” is often non‑trivial.

These risks point to a simple operational truth: treat VEX attestations as high‑quality signals for the products they cover, but do not let them short‑circuit artifact‑level verification across your estate.

---

Practical verification and mitigation checklist (what to do now)​

Below are concrete steps for administrators and defenders who want to convert the MSRC product attestation into operational certainty across their environment.

• Prioritize Azure Linux images immediately.
• If you run Azure Linux images, ingest Microsoft’s VEX/CSAF output, confirm whether your specific image versions are labeled “Known Affected,” and apply the kernel updates Microsoft publishes. Microsoft has stated it will update CVE mappings when additional products are found to ship affected components; for Azure Linux customers, treat the Microsoft attestation as authoritative.
• Inventory other Microsoft‑supplied artifacts and images.
• Make a list of all Microsoft‑provided or Microsoft‑curated artifacts you run: WSL2 kernels bundled with Windows, linux‑azure kernel builds, Marketplace/partner VM images, AKS/managed node images, and any OEM‑branded Microsoft appliances.
• For each artifact, determine the kernel version and whether PREEMPT_RT is enabled, then map that against the CVE version ranges from tracker entries. Vendor advisories and NVD entries include the upstream affected ranges and patches.
• Use targeted artifact checks on Linux hosts.
• Check kernel version: uname -a
• Check kernel config for RT: grep PREEMPT_RT /boot/config-$(uname -r) || zgrep PREEMPT_RT /proc/config.gz
• Search for rcutorture or test modules: rpm -ql kernel-core | grep -i rcutorture ; dpkg -L linux-image-$(uname -r) | grep -i rcutorture ; find /lib/modules/$(uname -r) -type f -iname 'rcutorture'
• Inspect dmesg and journal for the specific splat pattern: journalctl -k | grep -i rcutorture or dmesg | grep -i rcutorture
• If you maintain image builds, search your build trees for the rcutorture sources (rcu/rcutorture.c) or test Kconfig entries.
• Patch or re‑build as needed.
• If an artifact includes the rcutorture code and uses PREEMPT_RT, update that artifact to a kernel build that contains the upstream fix. Upstream stable patches are available and distributor advisories list which packaged versions resolve the issue.
• If you build your own kernels, cherry‑pick the vendor or kernel.org fixes into your tree and run your CI/QA matrix to validate the RT behavior before deployment.
• Harden test and CI environments.
• Avoid shipping test harnesses and stress tools in production images. Ensure your CI runners that execute kernel torture suites are isolated from sensitive production networks.
• Limit who can install or enable PREEMPT_RT kernels in production; document the justification and implement monitoring for kernel changes.
• Monitor Microsoft’s VEX/CSAF feed and the CVE record.
• Subscribe to MSRC’s VEX/CSAF outputs and to the CVE record for updates. Microsoft has explicitly said it will update CVE/VEX entries if additional Microsoft products are discovered to ship the component. Treat new attestations as potentially action‑triggering events for other artifacts you rely on.
• If you rely on third‑party scans, verify their artifact mapping.
• Threat and vulnerability management platforms often rely on CVE feeds. Confirm that these scanners map CVEs to the precise artifact builds you run and that they are not only flagging “Azure Linux (affected)” without telling you whether your image is impacted.

---

Quick‑reference commands and checks​

• Show kernel version:
• uname -a
• Check whether the kernel was built with PREEMPT_RT:
• grep PREEMPT_RT /boot/config-$(uname -r) || zgrep PREEMPT_RT /proc/config.gz
• Search for rcutorture in installed modules or packages:
• find /lib/modules/$(uname -r) -type f -iname 'rcutorture'
• rpm -qa | grep -i kernel ; rpm -ql kernel-core | grep -i rcutorture
• dpkg -l | grep linux-image ; dpkg -L linux-image-$(uname -r) | grep -i rcutorture
• Inspect kernel logs for the reported splat:
• journalctl -k | grep -i 'rcutorture_one_extend_check'
• dmesg | grep -i rcutorture
• Map kernel version to CVE vendor advisories:
• Consult NVD and your distro advisories for affected version windows; for example, upstream trackers list selective 6.15/6.16 windows as affected for this CVE.

These steps give you a fast way to triage hosts; for fleets, automate these checks and feed results into your vulnerability manager.

---

Cross‑checks, evidence and independent corroboration​

To avoid single‑point reliance, defenders should cross‑check at least two independent sources before concluding that a given artifact is unaffected:

• The NVD overview and CVE record provide canonical upstream descriptions and are a foundational reference for affected ranges and severity.
• Distributor advisories (for example Amazon Linux ALAS, Red Hat errata, vendor blog posts) provide mapping from the upstream CVE to packaged kernel versions and offer timelines for repositories and security updates. Amazon’s advisory listings and other distro trackers flagged this CVE and listed status for their kernel streams.
• Upstream kernel patches (the kernel.org commits addressing rcutorture_one_extend_check) provide the authoritative code fix and a technical explanation of the root cause. When practical, inspect the patch to understand whether the fix sits in test code or in core kernel branches. Vendor advisories and cross‑vendor trackers typically link to kernel.org patches.
• Microsoft’s machine‑readable VEX/CSAF attestations (and the MSRC blog describing the VEX rollout) establish the product‑level inventory Microsoft has completed and make clear the attestation scope and update commitments. These are a critical input for Azure Linux customers.
• Community explainers and operational posts — for eage in specialist forums and vendor security blogs — help translate the technical fix into operational remediation steps. Use them to validate your patching plan.

If any of those sources disagree, prioritize primary artifacts (kernel.org commits and vendor advisories) and treat other reporting as context.e on exploitation and practical severity
CVE‑2025‑39745 is best characterized as a medium‑impact robustness/availability defect specific to RT kernels exercising kernel test code. Trackers give it a moderate CVSS score and distributors label it as needing patching for affected images; there is no evidence this CVE produces a remote code execution primitive or a widely weaponizable exploit in normal production configurations. The practical severity for most users will therefore hinge on whether they run RT‑configured kernels and whether their images include the rcutorture harness. For Azure Linux customers, Microsoft’s VEX/CSAF attestation and subsequent patch releases are the authoritative remediation path.

---

Final analysis and guidance for defenders​

• Short answer to the user’s question: No — Azure Linux is not the only Microsoft product that could include the implicated open‑source component. It is the only Microsoft product Microsoft has publicly attested, via VEX/CSAF, to include the component so far; that attestation is authoritative for Azure Linux, but it is deliberately limited in scope. Absence of attestations for other Microsoft artifacts is not proof they are unaffected.
• Practical next steps:
• Treat Microsoft’s Azure Linux attestation as a definitive “in scope” signal for Azure Linux images and patch those images promptly using Microsoft’s guidance.
• Inventory and verify other Microsoft artifacts you run — WSL kernels, linux‑azure builds, Marketplace and AKS node images — using the artifact checks above to determine whether they carry rcutorture and whether they were built with PREEMPT_RT.
• Update kernels to vendor‑published patched versions where applicable; if you maintain bespoke kernel builds, apply the kernel.org fixes and validate behavior in RT testbeds before deployment.
• Ingest Microsoft’s VEX/CSAF data programmatically and subscribe to CVE/attestation updates so you are notified if Microsoft expands the set of affected products.
• Why this approach matters: product‑scoped attestations significantly raise the signal‑to‑noise ratio for defenders, but they do not replace per‑artifact verification. A disciplined program that combines machine‑readable attestations (VEX/CSAF), upstream patch inspection, and automated artifact scanning will close the remaining gaps and prevent assumptions from becoming vulnerabilities.

---

The rcutorture fix is a technical, limited‑scope kernel correction, and for many organizations it will represent a low operational risk — provided they perform the modest verification steps above and prioritize repairs where PREEMPT_RT and test‑harness code intersect. Microsoft’s transparent VEX/CSAF rollout is an important step forward; treat its attestations as high‑quality signals for the products they cover, but continue to verify every artifact you run.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center