The short answer is: Microsoft has publicly attested that Azure Linux (the distro formerly known as CBL‑Mariner) includes the upstream component implicated by CVE‑2024‑26909 and is therefore potentially affected, but that attestation is a product‑scoped inventory statement — it is not a categorical guarantee that no other Microsoft product or artifact could contain the same vulnerable kernel code. (msrc.microsoft.com)
CVE‑2024‑26909 is a Linux kernel defect described as "soc: qcom: pmic_glink_altmode: fix drm bridge use‑after‑free." The problem is a race condition in the Qualcomm PMIC GLINK altmode driver where a DRM bridge pointer can be registered or stored before all resources are safely acquired; under certain probe‑deferral scenarios this can lead to the bridge being deregistered and its memory freed while another path still references it, producing a use‑after‑free (UAF) and, in practice, occasional display initialization failures or kernel NULL‑dereferences on affected platforms. The upstream discussion and patch series were discussed on the Linux kernel mailing list and applied as small, surgical fixes to the relevant driver code.
This is a local, kernel‑space reliability/security bug (CVSSs in public trackers indicate medium severity), not a remote, unauthenticated remote‑code‑execution zero day; practical impact is typically denial‑of‑service (display subsystem failure, kernel oops) on systems that include the impacted driver and run the triggering code paths. Public vulnerability feeds and vendor advisories note that stable kernel releases including the fix are available and recommend updating to fixed kernel versions.
Concrete examples of Microsoft artifacts that could carry the same upstream kernewarrant verification:
Microsoft has been explicit that it began publishing CSAF/VEX in October 2025 and that the initial phased rollout started with Azure Linux; this clarifies intent and timelines for customers who depend on machine‑readable advisories to automate vulnerability response. Treat those VEX files as authoritative for the product stated and monitor them for expansion to other Microsoft product families.
Actionable next steps for security teams: inventory Microsoft‑supplied artifacts in your environment; check kernel versions and CONFIG flags (look for CONFIG_QCOM_PMIC_GLINK / pmic_glink_altmode); patch or apply mitigations where the driver is present and the kernel is unpatched; and integrate Microsoft’s VEX/CSAF feeds into your automation while retaining artifact‑level verification for non‑attested items. Combine upstream patch references and vendor advisories when planning rollouts, and remember: an attestation for Azure Linux is a starting point — not a final answer for every Microsoft artifact.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE‑2024‑26909 is a Linux kernel defect described as "soc: qcom: pmic_glink_altmode: fix drm bridge use‑after‑free." The problem is a race condition in the Qualcomm PMIC GLINK altmode driver where a DRM bridge pointer can be registered or stored before all resources are safely acquired; under certain probe‑deferral scenarios this can lead to the bridge being deregistered and its memory freed while another path still references it, producing a use‑after‑free (UAF) and, in practice, occasional display initialization failures or kernel NULL‑dereferences on affected platforms. The upstream discussion and patch series were discussed on the Linux kernel mailing list and applied as small, surgical fixes to the relevant driver code.This is a local, kernel‑space reliability/security bug (CVSSs in public trackers indicate medium severity), not a remote, unauthenticated remote‑code‑execution zero day; practical impact is typically denial‑of‑service (display subsystem failure, kernel oops) on systems that include the impacted driver and run the triggering code paths. Public vulnerability feeds and vendor advisories note that stable kernel releases including the fix are available and recommend updating to fixed kernel versions.
How Microsoft has described the issue
Microsoft’s public Security Update Guide / MSRC VEX/CSAF outputs for CVEs in 2024–2025 follow a pattern: the company inventories the components inside specific product families and publishes machine‑readable attestations indicating whether a named Microsoft product is Known Affected, Not Affected, Under Investigation, or Fixed. For this class of upstream Linux kernel fixes Microsoft has, in many cases, explicitly listed Azure Linux as a product that includes the implicated upstream code and is therefore potentially affected; Microsoft also states it will update the CVE/VEX record if additional Microsoft products are identified as carriers. That is the published position and operational commitment. (msrc.microsoft.com) ([microsoft.com](Toward greater transparency: Introducing Machine-readable Vulnerability Exploitability Xchange (VEX) for Azure Linux and beyond independent community summaries and forum explainers — and even Microsoft’s own documentation about its phased VEX rollout — make the same practical point: the Azure Linux attestation is authoritative for Azure Linux images in scope, but it does not prove exclusivity across the whole Microsoft product set. Treat an Azure Linux attestation as a product‑level inventory result; other Microsoft artifacts remain “unverified” until Microsoft attests them or the artifact is inspected.Technical reality: why a "Yes for Azure Linux" statement is not the same as "No for everything else"
There are three independent technical reasons the presence (or absence) of an upstream kernel source file in one Microsoft product does not automatically map to every Microsoft product:- Kernel artifacts are built per product and per release. A single vendor (Microsoft) can ship many independent kernel binaries and images (Azure Linux builds, linux‑azure packages for Azure VMs, the WSL2 kernel image used on Windows clients, Marketplace images and appliances, container host kernels used by AKS, and more). Each of those artifacts can use different kernel versions, different stable backports, and different CONFIG build flags. Whether the driver is present and whether it is built in or as a module depends on build‑time configuration.
- Inclusion is a file/module/configuration property. The upstream file (historically drivers/soc/qcom/pmic_glink_altmode.c and related code paths) may be present in many kernel trees, but whether it is compiled into a particular kernel depends on the Kconfig flags used when that kernel was built (for example the Qualcomm PMIC GLINK driver is gated by CONFIG_QCOM_PMIC_GLINK and historically produced the module pmic_glink_altmode). You must verify kernel config and module presence to know if a binary carries the code path.
- Microsoft’s VEX/CSAF rollout began as a phased program focused on Azure Linux. Microsoft chose to inventory that product first as a practical step. Being the first product to receive attestations is an operational choice, not a technical statement about exclusivity. Microsoft has repeatedly said it will update VEX/CSAF documents if additional Microsoft artifacts are found to ship the same code.
The CVE technical facts verified from upstream and public trackers
- Nature of bug: use‑after‑free in the Qualcomm PMIC GLINK altmode driver in the Linux kernel DRM bridge registration/teardown path. Triggered by probe deferral and transparent‑bridge rework in the DRM stack.
- Platforms reported in upstream discussion: devices using Qualcomm PMIC GLINK altmode support such as certain ThinkPad models surfaced display initialization symptoms in regression testing (examples in upstream threads reference Lenovo ThinkPad X13s behavioral observations). This demonstrates the issue was observable on hardware where the driver and the affected DRM code paths are exercised.
- Fix status: patches were submitted and applied to the kernel trees (stable backports exist). Public vulnerability trackers list fixed kernel versions and suggest updating beyond specific stable versions (public trackers suggest updating to kernel versions > 6.6.23 or > 6.7.11 depending on the branch). Operators should apply vendor kernels or upstream stable fixes as appropriate.
- Presence in kernel trees / build flag: the driver historically exists under drivers/soc/qcom with a Kconfig entry such asK that controls whether the module is built; LKDDb and kernel build metadata show the module name pmic_glink_altmode and list the driver as present in kernel series covering 6.3–6.19 and later branches before refactors. That makes kernel config checks the reliable detection method.
Is Azure Linux the only Microsoft product that includes this library?
Long answer: No — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) as including the implicated open‑source component for this CVE, and Microsoft has committed to update VEX/CSAF mappings if further Microsoft products are identified as carriers. But the lack of a public attestation for other Microsoft artifacts is not proof they are unaffected. Any Microsoft‑distributed artifact that ships a Linux kernel built from a version that contains the vulnerable driver — and that enabled or modularized the driver — could also be affected until verified or patched. (msrc.microsoft.com)Concrete examples of Microsoft artifacts that could carry the same upstream kernewarrant verification:
- WSL2 (Windows Subsystem for Linux) kernel image distributed by Microsoft to Windows clients. Microsoft publishes WSL kernel sources and distributes kernel binaries; whether a given WSL kernel build includes the Qualcomm driver depends on the version and configuration used for that WSL kernel. If your organization uses WSL on Windows devices that run on Qualcomm‑based hardware (uncommon but possible on ARM64 Windows devices), check those WSL kernel versions.
- linux‑azure / Azure‑tuned kernel packages that Microsoft and partners ship inside Azure VM images. These are separate kernel packages maintained for Azure VM images; they may incorporate kernel patches or backports. Multiple vendor kernel advisories for Azure kernels are routinely published by distro vendors (e.g., Ubuntu’s linux‑azure updates) and should be monitored.
- Azure Marketplace images, AKS node images, vendor appliances or partner images that include Microsoft‑curated kernels or kernel packages. Each image is an independent artifact and must be verified.
How to verify whether a given Microsoft artifact (or your image) includes the vulnerable driver
Use the following practical, low‑friction checks. These steps work for Linux hosts (Azure VMs, local server images, WSL instances) and for images you control.- Determine the kernel version running (or in the image):
- Run uname -r (inside the VM, container host, or WSL instance).
- Compare with the fixed kernel versions published by vendors/upstream (public trackers point to fixed releases and stable backports — for example see kernel stable patches and vendor advisories).
- Check kernel config for the Qualcomm PMIC GLINK flag:
- Inspect /boot/config-$(uname -r) or zcat /proc/config.gz | grep QCOM_PMIC_GLINK
- If CONFIG_QCOM_PMIC_GLINK is set to y (built-in) or m (module), the driver is present in that kernel build. LKDDb confirms this Kconfig item historically controls the pmic_glink_altmode module.
- If the driver is modular, check for module presence:
- lsmod | grep pmic_glink or modinfo pmic_glink_altmode (run as root).
- Search dmesg for “pmic_glink” or related strings to see if the driver loaded at boot.
- For WSL: check the shipped WSL kernel version:
- From a Windows prompt run wsl --status and inspect the kernel version, or check uname -r from inside a WSL2 distro. Microsoft publishes the WSL kernel source and release notes for the WSL kernel; ensure the WSL kernel has the upstream fix or is updated via Microsoft’s WSL update mechanism if needed.
- For images you don’t control (Marketplace images, partner appliances): assume unverified until you can obtain the image’s kernel version or until the vendor/publisher provides a VEX/CSAF attestation. If the image runs in your environment, treat it as in scope for inventory and patch‑planning.
Recommended mitigations and remediation steps
- Prioritize patching the kernel. The root remediation is to install a vendor‑supplied or upstrns the applied fixes. Public trackers list fixed kernel versions and the upstream git commits; vendors have backported fixes into their stable kernels where appropriate. Reboot after applying the updated kernel.
- For systems where immediate kernel updates are not possible, consider short‑term mitigations:
- If the affected module is built as a loadable module and the hardware in question does not require the PMIC GLINK altmode functionality, you can blacklist the module (for example by adding a modprobe blacklist entry) and rebuild initramfs to prevent it from loading. This is a targeted mitigation but may remove USB‑C/display functionality on affected hardware. Test before wide deployment.
- Isolate affected hardware in staging networks until the kernel is patched if the bug materially impacts availability of production hosts.
- For WSL on Windows endpoints: ensure Windows Update and WSL update flows are applied and follow Microsoft’s published guidance for updating WSL kernel binaries if Microsoft p kernel.
- Inventory and attest: add the following items to your vulnerability triage checklist:
- All Azure Linux images and Azure VM families (already attested by Microsoft).
- All linux‑azure / azure‑tuned kernels in your VM fleet.
- WSL2 clients in corporate endpoints (collect WSL kernel versions).
- Marketplace images, partner appliances, and custom images that include a Linux kernel.
- Any on‑prem or OEM systems that run Qualcomm‑based hardware where this driver is relevant.
- Monitor VEX/CSAF feeds and the MSRC Security Update Guide for updates: Microsoft has committed to update the CVE mappings if additional Microsoft product artifacts are identified as carriers; incorporate this machine‑readable feed into automation and SIEM alerting to flag product attestation changes.
Why this matters for defenders and enterprise operators
- Azure Linux attestation is actionable: if you run Azure Linux images, Microsoft’s VEX/CSAF statement puts those images in scope and signals immediate patch prioritization. The attestation is therefore extremely useful for automation and triage. (msrc.microsoft.com)
- The larger enterprise blast radius is artifact‑specific: organizations that consume Microsoft artifacts beyond Azure Linux (WSL, linux‑azure kernels, Marketplace images, AKS node images, vendor appliances) must not assume those artifacts are unaffected. Attack surface and exposure are determined by which kernel binary an image ships, which Kconfig flags were enabled, and whether backpoattestation’s explicitness is a help — treat it as a starting point and expand inventory coverage accordingly.
- False negatives are dangerous: relying on the presence of a single vendor attestation for “all Microsoft products” invites blind spots. For example, a WSL kernel or a Marketplace appliance could carry the same vulnerable driver if it used an affected kernel version and enabled that driver at build time. Routine artifact verification is essential in modern supply chains.
How Microsoft’s VEX/CSAF approach changes operational playbooks (and its limits)
Microsoft’s decision to publish machine‑readable VEX/CSAF attestations (a phased rollout that began with Azure Linux) is a substantive improvement for customers: it allows automated mapping of CVEs to specific Microsoft products and small‑footprint decision logic for remediation. That said, the operational limitation is inherent to a product‑scoped inventory approach: it requires iterative expansion of attestations to cover additional product families. Security teams should integrate VEX/CSAF as a primary signal for the products it covers, and retain artifact‑level verification for other vendor artifacts until Microsoft’s attestations explicitly cover them.Microsoft has been explicit that it began publishing CSAF/VEX in October 2025 and that the initial phased rollout started with Azure Linux; this clarifies intent and timelines for customers who depend on machine‑readable advisories to automate vulnerability response. Treat those VEX files as authoritative for the product stated and monitor them for expansion to other Microsoft product families.
Real‑world checklist for IT/security teams (step‑by‑step)
- Identify all Microsoft‑supplied Linux artifacts in your environment:
- Azure Linux images, linux‑azure kernels, AKS nodes, Marketplace images, vendor appliances, WSL installations on endpoints. Inventory by image manifest.
- For each artifact, collect kernel metadata:
- uname -r, /boot/config-$(uname -r), lsmod, modinfo, and dmesg snippets.
- Record whether CONFIG_QCOM_PMIC_GLINK (or similar QCOM PMIC flags) is present and whether pmic_glink_altmode is built as module or built‑in.
- Map kernel versions against fixed upstream and vendor backports:
- If kernel is older than fixed releases or vendor says “not fixed,” plan remediation. Public trackers list backport recommendations; vendors may have distro packages or kernel updates.
- Patch and reboot hosts in priority order:
- Start with Azure Linux instances (attested by Microsoft) and any systems where the driver is present.
- For Windows endpoints with WSL2, ensure WSL kernel is updated to a patched binary or contact Microsoft if the WSL kernel needs explicit update.
- Apply temporary mitigations where patching is delayed:
- Blacklist module or limit exposure of affected hardware until patching is possible. Test mitigations for operational impact.
- Subscribe to VEX/CSAF and MSRC feeds:
- Automate ingestion of Microsoft’s CSAF/VEX and other vendor advisories to catch attestation expansions or product mapping changes promptly.
Strengths and risks: a critical analysis
Strengths- Microsoft’s move to publish VEX/CSAF attestations is a significant operational improvement. It reduces noise and speeds triage for customers running Azure Linux by giving a machine‑readable “is this product in scope?” answer for the artifacts Microsoft has inventoried. This materially reduces time‑to‑action for in‑scope customers.
- Upstream fixes for CVE‑2024‑26909 are small and targeted. The patch series focuses on safe ordering of allocation/registration and closes the narrow race window, which makes vendor backports and stable kernel updates straightforward to produce and deploy. That reduces the long‑term blast radius when vendors ship timely fixes.
- The primary risk is inventory complacency: teams that treat a single product attestation as universal assurance risk leaving other Microsoft artifacts unverified. The reality of modern supply chains is many independent kernel images and binaries with varying config choices; absence of attestation is not evidence of absence.
- The VEX/CSAF rollout is phased. Until Microsoft explicitly attests additional product families (WSL, linux‑azure kernels, Marketplace images), customers must continue artifact‑level verification. Automation that relies solely on a single vendor's VEX feed for all artifacts will miss un‑attested but affected binaries.
- Operational complexity for endpoint clients: for many enterprises the hardest part is updating thousands of endpoints with WSL or managing vendor Marketplace appliances. These scenarios require processes for collecting kernel metadata and either orchestrating updates or applying acceptable mitigations.
Conclusion
Microsoft’s public statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate and important: it gives Azure Linux customers an authoritative, machine‑readable signal to prioritize remediation for CVE‑2024‑26909. However, it is not a universal exclusion for other Microsoft products. Any Microsoft artifact that ships a Linux kernel built from an affected kernel source and with the Qualcomm PMIC GLINK altmode driver enabled could also be affected until verified or patched.Actionable next steps for security teams: inventory Microsoft‑supplied artifacts in your environment; check kernel versions and CONFIG flags (look for CONFIG_QCOM_PMIC_GLINK / pmic_glink_altmode); patch or apply mitigations where the driver is present and the kernel is unpatched; and integrate Microsoft’s VEX/CSAF feeds into your automation while retaining artifact‑level verification for non‑attested items. Combine upstream patch references and vendor advisories when planning rollouts, and remember: an attestation for Azure Linux is a starting point — not a final answer for every Microsoft artifact.
Source: MSRC Security Update Guide - Microsoft Security Response Center
