CVE-2026-64039

What it actually does

This Linux kernel flaw affects the Qualcomm MSM DRM display snapshot/register-dump code. The vulnerable code incorrectly aligns snapshot data regions to 16-byte boundaries and mishandles unaligned DSI register regions, which can cause the kernel to read or dump data beyond the intended register range. Depending on kernel configuration and driver exposure, a local attacker may be able to trigger disclosure of sensitive kernel or device memory through display debug/snapshot interfaces and may also cause instability or denial of service due to incorrect memory handling, including the related over-allocation behavior fixed in the same patch.

Why it matters to the business

Systems using affected Linux kernels with Qualcomm MSM display hardware may expose sensitive low-level kernel or device state to a local attacker and may be susceptible to crashes or display subsystem instability. The practical risk is highest on embedded, mobile, IoT, appliance, and ARM-based platforms that enable the MSM DRM driver and expose debug or snapshot functionality. Although there is no known public exploit or CISA KEV listing at this time and EPSS is low, kernel issues can be difficult to monitor and should be remediated during the next appropriate kernel update cycle, with higher urgency for shared, kiosk, mobile, or physically accessible devices.

How an attack unfolds

An attacker first needs local code execution on a device running an affected kernel with the Qualcomm MSM DRM driver present and the relevant snapshot/debug functionality reachable. The attacker then interacts with the display snapshot or register-dump path, typically through kernel-exposed graphics/debug interfaces, and causes the MSM display snapshot code to process a DSI region whose start or length is not aligned as the old code expected. Because the vulnerable implementation aligns lengths rather than accurately respecting the actual region boundaries, the dump operation can include unintended adjacent data or perform incorrect memory handling. The attacker then collects the resulting output to recover leaked kernel or device-state information, or repeatedly triggers the path to attempt to destabilize the display subsystem or kernel.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the MSM DRM snapshot handling issue. The relevant fix removes the unsafe length alignment, prints the final registers accurately for unaligned regions, and corrects the memory overallocation in msm_disp_state_dump_regs(). If vendor kernels are used, obtain the patched kernel from the device, distribution, or silicon vendor rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling or restricting access to debugfs and display snapshot/debug interfaces, limiting local shell access, enforcing least privilege, and disabling unnecessary DRM/MSM debug functionality in production kernels where feasible.

How to confirm the fix worked

Confirm that the running kernel package or vendor firmware includes the MSM DRM snapshot fix referenced by the upstream drm/msm/snapshot patch. Validate by checking the kernel source or vendor patch set for corrected handling in the MSM display snapshot/register-dump code, especially removal of unsafe length alignment and the corrected msm_disp_state_dump_regs() allocation behavior. On running systems, confirm the kernel version/build date matches a patched vendor advisory or distribution update. Also verify that debugfs and display-driver diagnostic interfaces are not broadly accessible to untrusted local users, and that production systems do not expose unnecessary MSM display snapshot functionality.

Typical attack path

1. Obtain local execution on a Linux device using an affected kernel and Qualcomm MSM display hardware.
2. Confirm that the msm DRM driver and display snapshot/register-dump functionality are available.
3. Access exposed graphics, DRM, debugfs, or driver diagnostic interfaces associated with the MSM display subsystem.
4. Trigger snapshot dumping of an unaligned DSI data/register region.
5. Read the resulting snapshot or diagnostic output for unintended adjacent kernel/device data, or repeatedly trigger the condition to cause instability.
6. Use any disclosed information to support further local exploitation, bypass mitigations, or gather sensitive device state.

How to detect it

There are no widely reported public exploitation artifacts for this vulnerability at the time of analysis, so detection should focus on evidence of suspicious local access to MSM DRM, debugfs, and display snapshot/register-dump interfaces. Review auditd, EDR, shell history, sudo logs, kernel logs, and file-access telemetry for processes reading or traversing /sys/kernel/debug, /sys/kernel/debug/dri, DRM device nodes, or msm display snapshot-related paths. Look for unusual access by non-administrative users, repeated reads of display debug files, scripted collection of debugfs contents, or repeated kernel/display subsystem warnings or crashes following DRM debug activity. On embedded or mobile Linux platforms, also examine application sandbox escapes or local privilege-escalation chains that could have been used to reach kernel debug interfaces before triggering the issue.

• /sys/kernel/debug/dri
• /sys/kernel/debug/dri/0
• /sys/kernel/debug/dri/1
• msm_disp_state_dump_regs
• drm/msm/snapshot
• msm_drm
• dpu
• dsi
• /dev/dri/card0
• /dev/dri/renderD128
• cat /sys/kernel/debug/dri
• grep -R . /sys/kernel/debug/dri
• tar cf - /sys/kernel/debug
• debugfs
• drm:msm
• msm_disp_snapshot

What your security team should do

• Inventory Linux systems and embedded devices using Qualcomm MSM/Adreno display hardware or kernels with the msm DRM driver enabled.
• Prioritize vendor kernel or firmware updates for mobile, embedded, kiosk, shared-user, and physically accessible systems.
• Restrict local user access to debugfs, DRM diagnostic paths, and display snapshot interfaces until patched.
• Review kernel configuration and production hardening baselines to ensure debug-only display snapshot functionality is disabled or tightly controlled.
• Monitor vendor advisories for downstream fixed kernel versions, because affected status may vary across distribution and device-vendor kernel trees.
• Treat any evidence of local probing of MSM DRM debug or snapshot interfaces as suspicious, especially on systems where untrusted users can execute code.