Understanding CVE-2025-39721: Linux QAT Driver Flaw and Azure Linux Attestation

Microsoft’s entry for CVE‑2025‑39721 correctly flags Azure Linux as a distribution that “includes this open‑source library and is therefore potentially affected,” but that product‑level attestation is precisely that — an attestation, not a categorical statement that no other Microsoft product ships the same vulnerable code.

Background / Overview​

CVE‑2025‑39721 is a Linux kernel vulnerability in the Intel QuickAssist Technology (QAT) crypto driver family. The defect arises from the way the QAT stack manages a shared misc workqueue during device shutdown: if a device‑specific QAT module (for example, qat_4xxx) is unloaded while the core intel_qat module remains loaded and a deferred work item is still pending, that deferred routine can execute against freed driver state and trigger a kernel page fault or crash. The upstream remedy is to flush the shared misc workqueue during device shutdown so that no device‑specific deferred routines remain queued after their module has been removed.
The fix and advisory trail is conventional for a kernel bug: the CVE was recorded by the kernel CVE team, downstream distributions produced advisories and backports, and kernel maintainers supplied commits that add the workqueue flush and associated robustness checks. Stable commit identifiers were published alongside the advisory for operators who need to backport or verify fixes in an existing kernel tree.
Why this matters: QAT drivers are used to offload cryptographic and compression operations to dedicated hardware. While the issue is a use‑after‑free crash (availability impact) rather than a secret‑exfiltration cryptographic break, kernel crashes are severe for servers and appliance platforms — they can create DoS conditions or complicate recovery of systems performing sensitive workloads.

---

What Microsoft’s MSRC message actually says — and does not say​

Microsoft’s Security Response Center (MSRC) has taken to mapping upstream CVE reports to the Microsoft product inventory and publishing short product‑scope attestations (with machine‑readable CSAF/VEX records since October 2025). For CVE‑2025‑39721 (and many other Linux kernel CVEs), the public MSRC advisory notes that Azure Linux includes the implicated open‑source library and is therefore potentially affected, and that Microsoft will update the CVE mapping if additional Microsoft products are found to be impacted. That phrasing is intentionally narrow: it tells you what Microsoft has verified so far, and how it will handle further discovery. ([archive.ph](https://archive.ph/2025.12.07-21420...rability/CVE-2025-39762?utm_source=openaiarse that wording correctly:

• What it does mean: Microsoft examined Azure Linux builds or packages and confirmed that the upstream component tied to the CVE appears in those artifacts; Azure Linux customers should treat the distro as in‑scope for remediation and apply the published kernel or package updates.
• What it does not mean: It is not a guarantee that only Azure Linux can include the vulnerable QAT code. Absence of mention of other Microsoft products is not proof that other Microsoft images, kernels, appliances, or distributions do not carry the same upstream component. In other Microsoft advisories and community analysis, the same distinction has been emphasized repeatedly: product‑level attestations are authoritative for the named product, but not exclusive in scope.

In short: Microsoft is telling you what it has confirmed (Azure Linux) and promising to expand that inventory mapping if further artifacts are discovered to ship the vulnerable code. That is helpful — but it leaves an important operational question open for administrators who manage other Microsoft‑produced artifacts or who rely on Microsoft products in hybrid environments.

---

Does that mean Azure Linux is the only Microsoft product potentially affected?​

No — not necessarily.
The MSRC statement is an explicit, limited attestation: it confirms Azure Linux as a known carrier, and it commits Microsoft to update the CVE/VEX mapping if additional Microsoft products are identified as carriers. That is the right and transparent approach, but it does not logically exclude other Microsoft artifacts from being carriers of the same vulnerable upstream code. Historical MSRC advisories and community analysis consistently draw the same conclusion: an attestation naming Azure Linux is authoritative for Azure Linux but not proof of uniqueness across Microsoft’s product slate.
Examples of why the attestation is limited in scope:

• Microsoft produces multiple Linux‑based artifacts and kernels: Azure Linux images, CBL‑Mariner kernel builds, kernels embedded in device images, WSL2 kernel images shipped with Windows updates, and kernels used in some appliance or device firmware. Any of these artifacts could, in principle, include upstream Intel QAT driver code if the particular kernel configuration, modules, or packages were built into them.
• Microsoft also distributes or supports third‑party images in the Azure Marketplace and runs many customized system images across large fleets. Unless Microsoft has enumerated those artifacts and publicly attested them, e explicit scope of the single CVE attestation.

Therefore, while Azure Linux is the only Microsoft product Microsoft has publicly declared to include the vulnerable QAT code for CVE‑2025‑39721 at the time of the advisory, you should not treat that as a global guarantee that no other Microsoft artifact contains the same upstream code.

---

Technical summary of the bug and the fix​

The vulnerability in plain terms​

• The Linux kernel QAT stack keeps a shared "misc" workqueue (qat_misc_wq) owned by the core intel_qat driver.
• Device‑specific modules (e.g., qat_4xxx.ko) submit deferred work to that shared queue.
• If a device‑specific module is unloaded while a deferred routine is still pending — and a power management interrupt or tight load/unload loop times the event — the routine may run after the device module memory has been freed.
• That results in a kernel page fault or crash (use‑after‑free), producing OOPS logs like a fault in pm_bh_handler and a stack trace showing worker_thread/process_one_work entries.

What the fix does​

• The upstream fix ensures that the misc workqueue is flushed during device shutdown/unload so that any pending work items complete while the owning module context is still valid.
• The patch may slightly increase shutdown/unload latency because the flush must wait for queued jobs to finish, but it eliminates the use‑after‑free race and therefore improves kernel robustness. Kernel maintainers normally prefer correctness and safety over micro‑latency here.

---

Where the vulnerability shows up (which artifacts are typically affected)​

This issue is in upstream kernel driver code (drivers/crypto/intel/qat/*). That means any Linux image or kernel build that includes those driver files or builds the corresponding modules could carry the vulnerability prior to the fix. Common carriers include:

• Distribution kernels and packages (Ubuntu, SUSE, RHEL, etc.). Distribution advisories and patched package versions are the primary remediation path for most customers.
• Custom kernels embedded in appliances, virtual machine images, or cloud distro images (including Azure Linux). Microsoft’s attestation confirms Azure Linux images include the implicated upstream code. (archive.ph)
• Any kernel builds included with vendor images or marketplace images that include QAT drivers.
• Systems that rely on Intel QAT hardware and therefore load intel_qat and QAT device modules.

What you should not assume: a company or vendor label (including "Microsoft") by itself does not prove absence of the code; only an explicit, artifact‑level inventory or SBOM/attestation does that. Microsoft’s VEX/CSAF rollout offers machine‑readable inventory statements for Azure Linux and — as promised — will expand to other Microsoft product artifacts if the company finds them to be carriers.

---

Practical guidance for operators and administrators​

If you manage systems in environments that use Microsoft artifacts (Azure, Windows hosts with WSL, Microsoft appliance images, marketplace images), follow a risk‑based verification and remediation approach.

Step 1 — Confirm whether your systems include QAT drivers​

• On Linux systems, check whether the intel_qat or qat_4xxx modules are present or loaded:
• lsmod | grep -i qat
• modinfo intel_qat
• Search dmesg or kernel logs for QAT module messages or PM events:
• dmesg | grep -i qat
• On systems where you cannot run commands (immutable images), check the image SBOM, package manifest, or kernel configuration used to build the image.
• For Windows hosts that use WSL2, check the WSL kernel configuration or consult Microsoft’s WSL update notes to see if the kernel includes the intel_qat/qat module family.

These checks will tell you if the implicated driver family is present on the runtime artifact. If it is, treat that system in‑scope for remediation. If it is not present, the risk from CVE‑2025‑39721 is not applicable to that host. (Always treat the presence of modules and modules that can be loaded as the decisive signal.)

Step 2 — Patch or backport the fix​

• If you run a mainstream distribution, apply the vendor kernel/security update that includes the CVE fix. Most distributors (Ubuntu, SUSE, RHEL derivatives) published advisories and fixed kernel package versions or recommended stable kernel series that include the upstream commit.
• If you maintain a custom kernel, apply the upstream commits identified by the Linux CVE announcement (the kernel CVE lists include the exact commit IDs and stable backport candidates). Use the commit IDs in the kernel CVE announcement to cherry‑pick safely if you cannot upgrade the whole kernel at once.

Step 3 — If you run Azure Linux​

• Treat the MSRC attestation as an operational signal: Azure Linux images have been identified as carriers and should be remediated according to Microsoft’s published updates and the distro’s own update channels. Microsoft has committed to publish machine‑readable VEX/CSAF attestations to make this mapping programmatic; check the VEX for authoritative, artifact‑level status.

Step 4 — For other Microsoft artifacts (CBL‑Mariner, WSL, marketplace images)​

• Don’t assume safety: unless Microsoft has published a VEX/CSAF attestation for the particular artifact, verify by checking the artifact’s kernel build, SBOM, or package list.
• If you manage deployed instances (for example, marketplace VM images or appliance images), verify the kernel version and module list in‑place and apply vendor or image provider updates as appropriate.
• If uncertain, contact Microsoft support or file a security inquiry requesting a product‑level VEX/CSAF statement for the specific Microsoft artifact you rely on. Microsoft’s published process (CSAF/VEX) is precisely intended to enable this sort of programmatic verification.

---

Risk analysis: strengths and residual risks​

Strengths in Microsoft’s approach​

• Transparency via attestation: Publishing CSAF/VEX attestations and explicitly mapping CVEs to named Microsoft products is a strong step toward supply‑chain transparency. It gives Azure Linux customers a clear signal and a machine‑readable source of truth for inventory and risk automation.
• Conservative remediation: The upstream kernel fix prefers correctness (flushing the workqueue) over micro‑optimizations — a design choice that reduces the chance of regressions and racey behavior being reintroduced.
• Vendor coordination: Distribution and vendor advisories (Ubuntu, SUSE, RHEL) provide coordinated downstream fixes and guidance, which simplifies patching for typical enterprise environments.

Residual and systemic risks​

• Inventory blind spots: A single product attestation does not close the possibility that other Microsoft artifacts — kernels embedded in appliances, bespoke marketplace images, or older supported images — include the same upstream code. Customers can be vulnerable if they assume Microsoft’s one‑line attestation implies exclusivity.
• Operational lag in non‑standard artifacts: Custom images, edge devices, and appliances often receive less frequent kernel updates; if those images include QAT drivers, remediation could lag, extending windows of exposure.
• Detection complexity: QAT drivers can be built as modules and loaded on demand; absence of a loaded module at a given time does not necessarily mean the kernel has no capability to load the module later. Administrators must check the image’s module set or available package repo to be certain.
• Possible regression surface: While the fix is straightforward, any change to module unload semantics or workqueue behavior must be validated on platforms that exercise QAT hardware in production. Operators who perform in‑place backports should test on representative hardware to ensure no unintended interactions with QAT firmware paths or vendor SDKs occur.

---

How to validate Microsoft’s attestation and demand coverage​

Microsoft’s move to publish CSAF/VEX data is intended to make it possible for automation and for customers to request enumeration of other artifacts. Practical steps:

• Use Microsoft’s published VEX/CSAF feeds (or the MSRC update guide entries) to check whether a given CVE has been mapped to additional Microsoft products. For CVE‑2025‑39721, MSRC’s short note mapped Azure Linux and promised updates should other products be identified.
• Where you run Microsoft images you care about (marketplace images, WSL kernels, CBL‑Mariner kernels in appliances), request or locate the SBOM or kernel build manifest. If Microsoft has not published a VEX for that artifact, file a support/assurance request asking for confirmation and a VEX mapping.
• If you manage many hosts, integrate the VEX feeds into your vulnerability management system so that product mappings drive asset scoping automatically.

Note: the presence of an SBOM or VEX still requires operational verification. For high‑assurance environments, perform an image verification audit that checks the actual installed kernel package versions, module lists, and vendor backports.

---

What we’ve verified from trusted sources​

To ensure accuracy, this analysis cross‑checked multiple authoritative sources:

• The NVD and distributor advisories provide the canonical technical description of CVE‑2025‑39721 and the mitigation rationale (flush the misc workqueue during device shutdown).
• Distribution and vendor security pages (Ubuntu, SUSE, Red Hat references surfaced in vendor tracking systems) document which kernel packages and stable kernel trees include the fix or backports.
• The Linux kernel CVE announcement and stable commit listings identify the exact commits and files touched, enabling maintainers and administrators to verify or cherry‑pick the correct patch.
• Microsoft’s MSRC update guide uses the precise product‑scoping language quoted in the user’s prompt and commits to publishing VEX/CSAF mappings; that is the basis for treating Azure Linux as a confirmed carrier and for Microsoft’s promise to update mappings if more products are found impacted.
• Community and forum analyses (community posts and internal advisory threads) repeatedly emphasize the same interpretationamed carrier Microsoft has attested; the attestation is authoritative for Azure Linux but not an exclusivity guarantee for all Microsoft products.

If you need to trace the fix into a particular kernel tree or distribution package, follow the commits referenced in the kernel CVE announcement and the distribution security advisories; those links are provided in the kernel CVE notice and in downstream vendor bulletins.

---

Recommended checklist for IT teams (concise)​

• Inventory: Identify all hosts and images that run Linux kernels — including Azure Linux, CBL‑Mariner, WSL images, marketplace images, and appliance kernels.
• Detect: On each host, confirm whether intel*qat or any qat** modules exist (lsmod/modinfo/dmesg or SBOM checks).
• Patch: Apply vendor kernel updates or upstream commits that flush the QAT misc workqueue; if you cannot upgrade the kernel, cherry‑pick the stable commit after testing.
• Validate: Reboot and confirm the updated kernel is running (uname -a) and that QAT modules behave without the crash pattern.
• Automate: Ingest Microsoft’s CSAF/VEX mappings into vulnerability management to map CVE scope to assets when Microsoft publishes additional product attestations.
• Escalate: If you rely on Microsoft‑provided images not named in MSRC’s attestation, request a VEX or SBOM from Microsoft support to confirm the artifact’s status.

---

Final assessment and guidance for WindowsForum readers​

• Short answer: Microsoft has publicly attested that Azure Linux includes the upstream QAT code implicated by CVE‑2025‑39721; that makes Azure Linux a confirmed carrier and in‑scope for remediation. However, that attestation is product‑scoped and does not prove Azure Linux is the only Microsoft product that could contain the vulnerable code. Treat Microsoft’s wording as a confirmed inventory result for Azure Linux — but continue to verify other Microsoft artifacts yourself or request artifact‑level VEX/CSAF attestations for them.
• Evidence that supports this conclusion includes the upstream CVE description and kernel commits (NVD, kernel CVE announcement), downstream distribution advisories (Ubuntu, SUSE), and Microsoft’s own MSRC wording and VEX rollout commitment. Those multiple independent sources converge on the same operational facts: a QAT driver use‑after‑free was fixed upstream; Azure Linux has been identified as a carrier; Microsoft will expand mappings if it finds additional carriers.
• Bottom line for operators: assume risk until proven otherwise. If you manage or rely on any Microsoft images, kernels, or appliances beyond Azure Linux, verify whether the intel_qat/qat code exists in those artifacts and patch or backport the upstream fix as necessary. Use the newly available VEX/CSAF feeds to reduce manual effort, but always validate artifact contents for high‑assurance workloads.

CVE‑2025‑39721 is a classic kernel robustness bug with a clear fix and a manageable remediation path. Microsoft’s attestation for Azure Linux is useful and transparent — but it should be treated as a starting point, not the endpoint, for supply‑chain verification across the complex landscape of Microsoft‑distributed artifacts.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center