CVE-2024-45015: Linux MSM/DPU NULL Pointer Bug, Azure Linux Attestation, and Mitigation

A subtle null-pointer bug in the Linux kernel's DRM MSM/DPU display driver — tracked as CVE-2024-45015 — has been fixed upstream, and Microsoft’s public mapping currently lists Azure Linux as the only Microsoft product they have attested to include the affected open‑source component. That narrow public attestation, however, is not the same thing as proof of exclusivity: because this is an upstream kernel driver, any Microsoft artifact that ships a Linux kernel build with the MSM/DPU component enabled could plausibly carry the vulnerable code until it is verified or patched. This article unpacks the technical root cause, summarizes who is likely to be affected, explains what Microsoft’s attestation means in practical terms, and gives step‑by‑step operational guidance for administrators and vendors to find, verify, and mitigate exposure across Microsoft‑supplied artifacts and customer environments.

Background / Overview​

CVE-2024-45015 is a kernel-level bug in the drm/msm/dpu driver — the Direct Rendering Manager code that supports display hardware on Qualcomm MSM (Mobile Station Modem) SoCs. In specific sequences involving atomic mode-setting operations, the driver could dereference a NULL pointer and crash the kernel, producing a denial-of-service (DoS) condition. The upstream fix reorganizes when a connector is assigned to the DPU encoder and switches to retrieving that connector from the atomic state; this prevents the stale/cleared pointer access.
From a vendor‑mapping standpoint, Microsoft’s public advisory for the CVE identifies Azure Linux as the Microsoft product that includes the implicated open‑source library. Microsoft also states that they publish CSAF/VEX attestations and that they will update the CVE if additional Microsoft products are found to be impacted. This is an important operational point: the attestation identifies what Microsoft has validated so far, not an exhaustive inventory of every Microsoft artifact that could ever carry upstream Linux code.

---

What the bug actually is (technical overview)​

The atomic-mode dance: enable, disable, mode_set​

Linux DRM uses an atomic interface for mode setting and composition. Operations typically follow a lifecycle: compute a new atomic_state, perform an atomic_check() and, if checks pass, apply the state with sequences such as atomic_enable(), atomic_mode_set() and atomic_disable() depending on what’s changing.
CVE-2024-45015 arises in a corner case: when a CRTC’s connectors_changed flag is set but the enable / active state is not toggled, it is possible to execute an atomic_enable() followed by an atomic_disable() without an intervening atomic_mode_set(). In that flow the driver previously:

• Cleared or adjusted the encoder’s connector pointer in atomic_disable(); and
• Expected that a subsequent atomic_enable() would find the encoder’s connector re-assigned by atomic_mode_set()—but atomic_mode_set() never ran.

That mismatch leaves dpu_encoder_get_drm_fmt() looking up state through a connector pointer that has been cleared, producing a NULL pointer dereference in kernel context. The observable impact is a kernel panic or OOPS, which manifests as a crash and loss of availability.

The upstream fix​

The patch moves the encoder’s connector assignment into atomic_enable() and changes the lookup to use drm_atomic_get_new_connector_for_encoder() to retrieve the connector from the atomic_state rather than relying on a possibly stale in‑driver pointer. This change ensures the encoder sees a consistent connector value when enabling, eliminating the NULL dereference window.

---

Scope and severity: how bad is it?​

• Type of flaw: NULL pointer dereference (CWE-476).
• Primary impact: Availability (denial of service by kernel crash).
• Exploitability: Local‑vector; an attacker with the ability to trigger display mode changes or to cause the specific atomic sequence can provoke the crash. It is not a remote memory corruption allowing code execution in the kernel (i.e., no direct privilege escalation or confidentiality impact is implied by the bug alone).
• CVSS profile (operational): The vulnerability has been assessed as medium in several trackers; the attack surface is local and the primary effect is DoS.
• Affected kernel ranges: Upstream trackers identify affected kernel versions in stable branches and certain release candidates; because Linux distributions frequently backport fixes, a binary may be protected even if its nominal version number appears to be in an affected range.

Operationally, the bug is significant because kernel crashes are disruptive for services and devices, but it is not a silent remote escalation that steals data. It is important in contexts where display drivers are present and reachable (e.g., on devices with Qualcomm MSM GPUs or where those drivers are built into the kernel).

---

Microsoft’s public mapping: what “Azure Linux only” means — and what it doesn’t​

When a vendor such as Microsoft publishes a product mapping for a CVE and lists a product (for example, “Azure Linux”) as containing the implicated open‑source component, that mapping is an official statement of what the vendor has inspected and attested to at the time of publication. Microsoft’s language in the advisory for CVE-2024-45015 states that Azure Linux is the Microsoft product they have identified as including the open‑source library in question and that they will update the CVE if more Microsoft products are found to be impacted.
Important operational clarifications:

• Attestation is product‑scoped and time‑limited. The attestation confirms that Microsoft has identified the component in Azure Linux builds they manage and that they will supply VEX/CSAF data for it. It does not automatically guarantee that no other Microsoft product contains the same upstream code or that all Microsoft kernels are safe.
• Kernel contents are artifact‑specific. Two kernels built from the same upstream source can differ greatly depending on CONFIG_* build flags and vendor backports. A Microsoft kernel build that includes CONFIG_DRM_MSM or the relevant DPU code will carry the same code paths and therefore could be vulnerable if the fix is not present or not backported.
• Potential carriers beyond Azure Linux: Microsoft ships or maintains multiple Linux‑based artifacts that could, in principle, contain upstream DRM code depending on configuration and target architecture. Examples include WSL2 kernel builds (the WSL2 kernel is managed and published by Microsoft), specialized kernel images used in some Azure services or Marketplace appliances, and any custom kernel included in partner or device images that Microsoft distributes or co-manages.
• Absence of a mapping is not proof of absence. If a Microsoft product is not listed in the vendor's CVE mapping, that usually means it has not yet been confirmed (or it has been confirmed as not including the component). Vendors commonly update mappings as their inventory and verification work proceeds.

In short: Microsoft’s public note makes Azure Linux the only Microsoft product they have confirmed to contain the vulnerable code at publication time. That is authoritative and useful for Azure Linux customers, but it should not be taken as an exhaustive guarantee that no other Microsoft artifact could include the driver.

---

Who is actually at risk?​

Risk is determined by three independent conditions:

• The system runs a Linux kernel build that includes the drm/msm/dpu code (e.g., CONFIG_DRM_MSM).
• The kernel version or backport status does not already include the upstream fix.
• The environment exposes the driver to sequences or workloads that can exercise the affected atomic paths (platforms with display hardware and active users or processes that can trigger mode changes).

From that, the highest‑risk populations are:

• Devices and appliances with Qualcomm MSM SoCs running the impacted kernel driver (mobile devices, embedded boards, specialized appliances).
• Systems whose kernel builds include the MSM/DPU driver even if the hardware is not Qualcomm; distributions sometimes include many drivers to keep packages generic for multiple architectures.
• Azure Linux images and customers running those images, because Microsoft has attested that Azure Linux build(s) include the implicated component and will publish remediation notes / VEX attestations.
• Any Microsoft‑distributed Linux artifacts which have not been explicitly attested yet but are built from upstream sources that might contain the driver.

Lower‑risk targets include typical x86_64 server images where the msm driver is not built in or where the kernel configuration excludes the relevant driver. However, because cloud and appliance kernels can be configured broadly, administrators should not assume safety without verification.

---

How to detect whether your kernel is vulnerable (operational checks)​

You must verify presence at the artifact level. Do not rely solely on published version numbers; check kernel configuration and module presence.

• Check kernel config for driver build flags:
• If available on the running system, run:
• zcat /proc/config.gz | grep -i DRM_MSM (or)
• grep -i DRM_MSM /boot/config-$(uname -r)
  Look for CONFIG_DRM_MSM=y or m and any DPU/encoder related flags.
• If you cannot access a config file, consult the distribution package that provides the kernel image to see its build configuration.
• Check loaded modules and device nodes:
• lsmod | grep msm — will show msm or related modules if loaded.
• Inspect /dev/dri/ to see DRM device nodes; presence indicates a DRM subsystem in use.
• Verify the kernel package’s changelog or vendor advisory:
• Many distros and vendors publish package changelogs or security advisories that explicitly reference upstream commits; check those to see whether the fix was backported into your exact package.
• For Microsoft‑supplied artifacts:
• Azure Linux customers should consult Microsoft’s security update guidance and the CSAF/VEX attestation for this CVE to see which specific kernel package and build was confirmed to contain the code and whether a patched package is available.
• WSL users: check the WSL kernel build source and the official WSL kernel binary/version being used; if you run a custom WSL kernel, inspect its config as above.

If you find CONFIG_DRM_MSM enabled and your kernel package predates a known patched upstream commit (or there is no evidence of the fix being backported), treat the system as potentially vulnerable until patched.

---

How to remediate and mitigate​

The definitive remediation is to install a kernel build that includes the upstream fix or a vendor backport of that fix. Where immediate patching is impossible, apply mitigations to reduce attack surface.
Primary remediation steps:

• Install vendor‑supplied kernel updates as soon as they are released. For Azure Linux, apply the kernel package updates Microsoft releases for the distribution image. Verify the package changelog references the upstream fix or the specific CVE.
• If vendor updates are unavailable, apply upstream patches or rebuild kernels with the patch applied. For organizations that maintain custom kernels, apply the upstream commit that moves the connector assignment into atomic_enable() and rebuild according to your release process.
• Confirm backport status. Some stable kernels may have the fix backported even while the version number appears in an affected range; verify the patch level by checking package changelogs or by searching the kernel tree in the package.

Short‑term mitigation options:

• Restrict access to DRM devices:
• Limit who can access /dev/dri/* nodes using udev rules and file permissions, preventing unprivileged users from triggering display mode changes that exercise the vulnerable path.
• Harden container/user namespaces: Prevent untrusted containers and unprivileged users from accessing GPU/display devices.
• Use system monitoring and crash detection: Ensure kernel panics and OOPS events are captured in logs and alerting pipelines to speed incident response if a DoS occurs.
• Consider kernel livepatch (where supported): If your vendor supports livepatch and supplies a livepatch for the fix, apply it to reduce downtime.

Note: There is no substitute for installing the upstream or vendor‑backported kernel fix when it is available. Mitigations reduce risk but do not eliminate the underlying vulnerability.

---

Practical guidance for Microsoft customers and administrators​

If you run Microsoft‑published images or artifacts, follow these steps to reduce uncertainty and manage risk:

• Treat Microsoft’s Azure Linux attestation as authoritative for Azure Linux images. If Microsoft lists Azure Linux as containing the affected component, apply the kernel updates Microsoft provides for Azure Linux images as your first action.
• Inventory Microsoft‑supplied Linux artifacts in your environment. Don’t assume that only Azure Linux could be affected. Confirm whether any other images, appliances, Marketplace items, or WSL kernel builds you use are Microsoft‑managed and whether they include DRM/MSM drivers.
• For WSL users and admins: If you use the Microsoft‑provided WSL kernel binary, check the kernel version and consult Microsoft’s advisory mapping or WSL release notes. If you use a custom WSL kernel, inspect its config and rebuild with the upstream fix applied if necessary.
• Communicate with suppliers and partners. If you run Marketplace images or partner appliances that include Microsoft components, ask vendors to confirm whether their kernels include the MSM/DPU code and whether patches have been applied.
• Monitor vendor advisories and CSAF/VEX feeds. Microsoft has committed to VEX/CSAF publication; those feeds will be updated as Microsoft’s inventory work proceeds. Integrate those feeds into your vulnerability management process to automate product‑level mapping where possible.
• Perform artifact‑level verification before de‑risking. A kernel package build and its CONFIG_* settings are the final source of truth. Validate the presence of CONFIG_DRM_MSM and whether the package contains the upstream fix.

---

Supply‑chain and risk analysis: why a product attestation isn’t the full story​

Upstream code flows into many downstream artifacts. For kernel CVEs in particular:

• Build-time configuration matters. A distro can ship a kernel configured without the offending driver and therefore be safe, or it can include many drivers for broad hardware compatibility and thus be exposed.
• Backports complicate simple version checks. A vendor can backport a small security fix into an older kernel branch, meaning a package with an older version number may already contain the remedy.
• Vendor inventory work is incremental. Large vendors may publish an attestation for one product early because it was prioritized or because the artifact is used by many customers (e.g., cloud images). As teams inventory other artifacts (WSL kernels, Marketplace images, partner appliances), they may add additional mappings to the same CVE.
• Operational implication for defenders: Don’t rely on a single product statement as the full truth. Use artifact inspection and vendor package data to ascertain exposure across your environment.

Because CVE‑level vendor mappings are snapshots, defenders should expect iterative updates and should maintain an evidence‑based verification process (kernel configs, module presence, package changelogs) to confirm whether an artifact is vulnerable.

---

Example detection checklist (quick operational playbook)​

• For each host or image in scope:
• Obtain uname -r and identify the kernel package.
• Retrieve the kernel config (/boot/config-$(uname -r) or /proc/config.gz) and search for DRM_MSM.
• Check lsmod and dmesg for msm/dpu/drm messages.
• For each kernel package:
• Inspect the vendor changelog (package metadata) for references to the CVE or to the upstream commit ID.
• If no explicit mention exists, treat it as potentially needing patching unless config proves the driver is not present.
• For WSL or custom kernels:
• Inspect the WSL kernel configuration or the custom kernel’s .config.
• If custom builds are used in production appliances, add them to the rebuild/patch schedule.
• For Azure Linux:
• Track the patch or kernel package Microsoft releases for Azure Linux and apply it through normal image management/patching processes.

---

Longer‑term recommendations for vendors and operators​

• Automate artifact inspection. Integrate kernel config extraction and package changelog parsing into your vulnerability management pipelines so that binary‑level checks supplement CVE trackers.
• Publish clear VEX/CSAF attestations. Vendors should expand product mappings where appropriate and communicate whether fixes were backported or whether specific builds are unaffected due to config choices.
• Adopt least‑privilege access to device nodes. Restrict access to /dev/dri/* and similar devices so that untrusted workloads cannot trivially exercise kernel drivers.
• Encourage reproducible kernel builds and configuration transparency. When organizations can quickly inspect what features are enabled in a binary, triage and remediation are much faster.
• Consider kernel livepatch coverage. For environments that require high uptime, encourage patch providers to supply livepatches for kernel security fixes where technically feasible.

---

Final assessment and takeaway​

CVE-2024-45015 is a medium‑severity NULL pointer dereference in the Linux DRM MSM/DPU driver that can cause kernel crashes and availability loss. Microsoft’s public advisory listing Azure Linux as the product that includes the affected open‑source component is authoritative for Azure Linux customers and should be treated as an actionable remediation signal for those images. However, because the vulnerable component is part of the upstream kernel tree, other Microsoft artifacts that ship Linux kernels — including WSL kernel builds, Marketplace images, or bespoke appliances — could include the same driver depending on how they were built and what was backported.
Administrators should verify kernel configuration and module presence at the artifact level, apply vendor‑supplied kernel updates or upstream patches promptly, and use short‑term mitigations where necessary to reduce exposure until patched kernels are deployed. Vendors and operators alike should treat CVE product mappings as evolving; absence from a vendor’s mapping is not guaranteed protection, and the definitive test is a binary inspection of the kernel build and package changelog.
If you manage Azure Linux images, treat Microsoft’s attestation as a priority signal and apply the provided kernel updates. If you operate other Microsoft‑distributed Linux artifacts, perform the artifact‑level checks described above. The fix exists upstream and in vendor backports — the remaining work is verification, patching, and closing the window of exposure across all artifacts in your environment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center