CVE-2026-64153

What it actually does

This is a Linux kernel flaw in the MSM DRM graphics driver’s handling of iommu_map_sgtable() return values. A kernel API changed from returning zero on failure to returning negative error codes, but the driver did not correctly validate that signed return value. When the mapping operation fails, the vulnerable code can mis-handle the error path and trigger a kernel warning or unsafe failure behavior in a privileged kernel context. Because the issue is in kernel-space graphics/IOMMU handling, a local low-privileged user with access to the affected device interface may be able to cause denial of service and, depending on reachable code paths and kernel configuration, potentially impact confidentiality or integrity through kernel-level fault behavior.

Why it matters to the business

Successful exploitation could disrupt systems that rely on affected Linux kernels, especially devices or workloads using Qualcomm/MSM DRM graphics components. The most likely operational impact is local system instability, kernel warnings, crashes, or service interruption; the assigned severity also indicates potential for broader kernel compromise if an attacker can reliably weaponize the faulty error handling. The issue is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, so urgency should be driven primarily by whether affected kernels and MSM DRM hardware support are present in production or embedded fleets.

How an attack unfolds

An attacker first needs local code execution with low privileges on a system running an affected Linux kernel and exposing the vulnerable MSM DRM path. They interact with the graphics/DRM device interface in a way that causes an IOMMU scatter-gather table mapping operation to fail. On vulnerable kernels, the driver checks the iommu_map_sgtable() return value using outdated assumptions and does not properly treat negative return values as errors. This can push execution into an incorrect error path and trigger a kernel WARN or other unsafe kernel behavior. In practical exploitation, an attacker would repeatedly exercise the vulnerable driver path to cause a kernel fault, crash, or attempt to shape the failure into a more serious kernel compromise. There is currently no public evidence of exploitation in the wild or ransomware use based on the supplied intelligence.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the upstream DRM/MSM fix for correct iommu_map_sgtable() signed return-value handling. Because no exact fixed package versions were provided, use the fixed kernel releases published by the operating system, device, or appliance vendor and verify the patch is included in the running kernel source or changelog. Where immediate patching is not possible, reduce exposure by disabling or removing unneeded MSM DRM graphics support, restricting access to DRM device nodes such as /dev/dri/* to only trusted users and services, limiting local shell access, and applying standard kernel hardening controls. Mitigations should not be treated as equivalent to patching because the vulnerable code resides in kernel space.

How to confirm the fix worked

Confirm the running kernel version and vendor build include the DRM/MSM fix that stores the iommu_map_sgtable() return value as a signed ssize_t and returns negative errors instead of issuing WARN behavior. Validate through vendor advisories, kernel changelogs, source inspection, or package metadata. On systems where MSM DRM is not used, confirm the vulnerable driver is absent, not loaded, or not reachable. Operationally, review dmesg or journald kernel logs after patching and during graphics/IOMMU exercise to ensure no WARN traces related to drm/msm or iommu_map_sgtable() appear. Also verify /dev/dri permissions are restricted to expected groups and that untrusted users cannot access graphics device interfaces unnecessarily.

Typical attack path

1. Obtain local low-privileged execution on a Linux system running an affected kernel.
2. Confirm the MSM DRM graphics driver and relevant DRM device nodes are present and accessible.
3. Invoke graphics/DRM operations that reach the MSM driver’s IOMMU scatter-gather mapping path.
4. Force or induce iommu_map_sgtable() failure conditions that return negative error values.
5. Trigger the vulnerable error handling path that misvalidates the signed return value.
6. Cause kernel warning, instability, denial of service, or attempt further kernel-level exploitation.

How to detect it

To determine whether this was already exploited or attempted, review local kernel telemetry rather than network logs, because exploitation requires local interaction with kernel device interfaces. Primary sources include dmesg, journald kernel facility logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, auditd logs for access to /dev/dri/*, and endpoint process execution history around the time of kernel warnings or crashes. Look for repeated WARN, oops, panic, or kernel taint events referencing drm/msm, msm_drm, IOMMU mapping, scatter-gather mapping, or iommu_map_sgtable(). Correlate these events with local users or processes opening DRM render/card device nodes. Absence of these artifacts does not prove non-exploitation, but repeated local-triggered kernel warnings or crashes involving this driver path should be investigated as possible exploitation or fuzzing activity.

• iommu_map_sgtable
• drm/msm
• msm_drm
• iommu_map_sg
• WARNING: CPU:
• kernel: WARNING
• kernel: Oops
• Kernel panic
• BUG: kernel NULL pointer dereference
• /dev/dri/card0
• /dev/dri/renderD128
• /var/log/kern.log
• /var/log/messages
• dmesg

What your security team should do

• Inventory Linux systems, embedded devices, mobile-derived platforms, and appliances that may include Qualcomm/MSM DRM graphics support.
• Prioritize patching systems where affected kernels, MSM DRM hardware support, and local multi-user access coexist.
• Apply vendor kernel updates that include the upstream DRM/MSM iommu_map_sgtable() return-value fix.
• If patching is delayed, restrict access to /dev/dri/* and remove unnecessary local user access to affected systems.
• Monitor kernel logs for WARN, oops, panic, or taint events involving drm/msm, MSM DRM, IOMMU, or iommu_map_sgtable().
• Treat repeated local kernel warning or crash activity from graphics interfaces as suspicious, especially on shared or exposed compute platforms.
• Track vendor advisories for exact fixed kernel package versions, since fixed versions were not provided in the input intelligence.