CVE-2026-64231

What it actually does

This is a Linux kernel denial-of-service flaw in the Qualcomm MSM DRM DSI display driver. On DSI 6G platforms, the driver adjusts the mapped I/O base address by an internal io_offset, but the register dump size used during display snapshot capture was not reduced by the same offset. When the snapshot path attempts to dump registers, it can read beyond the mapped MMIO region and touch unmapped kernel address space, causing a kernel fault, oops, panic, or device reboot. The primary impact is local or device-adjacent availability loss rather than data theft or remote code execution based on the available description.

Why it matters to the business

Affected Linux-based systems using Qualcomm MSM/DSI display hardware may crash or reboot when the vulnerable display snapshot path is triggered, which can interrupt mobile, embedded, kiosk, automotive, IoT, or appliance workloads that depend on continuous device availability. The current EPSS score is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad opportunistic exploitation is not currently indicated; however, kernel crashes on endpoint or embedded fleets can still create operational disruption, support cost, and reliability risk.

How an attack unfolds

An attacker would need access to an affected device and a way to trigger the MSM display snapshot or register-dump path exposed by the kernel, typically through a local interface, diagnostic pathway, debug facility, vendor crash-collection mechanism, or another component that requests display-state capture. On vulnerable DSI 6G hardware, the driver computes an adjusted register base using io_offset but continues to use the unadjusted control-region size when adding the register block to the snapshot. The dump operation then attempts to access addresses beyond the mapped MMIO range. The kernel detects the invalid access and records an oops or panic with MSM display snapshot functions in the stack trace, potentially rebooting the system or leaving it unavailable until recovery.

How to fix it

Update to a Linux kernel or vendor device firmware build that contains the upstream fix for the MSM DSI register dump bounds calculation. The fix lowers the register dump control size by the io_offset value so snapshot capture does not access beyond the mapped region. Because no exact product list or fixed package versions were provided, track the relevant distribution, Android device, embedded vendor, or SoC vendor advisory and deploy the first kernel/firmware release that includes the drm/msm/dsi patch associated with Patchwork 721747. If immediate patching is not possible, reduce exposure by disabling or restricting access to display debug, snapshot, register-dump, and diagnostic interfaces; ensure debugfs is not available to untrusted users; limit local shell/ADB/diagnostic access; and use watchdog/recovery controls to reduce outage duration after a crash.

How to confirm the fix worked

Confirm the running kernel contains the patched drm/msm/dsi change that subtracts io_offset from the dumpable control-region size before snapshot registration. Validate through vendor release notes, kernel source inspection, package changelogs, or symbol/source comparison against the fixed patch. On test hardware matching the affected DSI 6G platform, safely exercise display snapshot collection and confirm it completes without kernel oops, panic, or out-of-bounds MMIO access. Also verify that untrusted users cannot access debugfs, display snapshot controls, or vendor diagnostic interfaces capable of triggering the path.

Typical attack path

1. Identify a Linux-based target using Qualcomm MSM DRM/DSI display hardware, especially DSI 6G platforms.
2. Obtain local, application-level, diagnostic, or privileged access sufficient to trigger display snapshot collection or register dumping.
3. Invoke the affected MSM DSI snapshot path repeatedly or at a timing useful for disruption.
4. The vulnerable driver attempts to dump registers using a size that extends past the mapped I/O region.
5. The kernel faults on access to unmapped memory, producing an oops, panic, hang, or reboot.
6. Repeat triggering if persistent denial of service is the attacker’s goal.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs and persistent crash storage. Relevant sources include dmesg, journalctl kernel logs, /var/log/kern.log, Android logcat kernel buffers, pstore, ramoops, kdump/vmcore artifacts, device crash reports, watchdog reset logs, and fleet telemetry showing unexpected reboots. Search for kernel oops or panic events with stack traces containing MSM display snapshot functions such as msm_disp_snapshot_add_block, msm_dsi_host_snapshot, msm_dsi_snapshot, msm_disp_snapshot_capture_state, msm_disp_snapshot_state_sync, or _msm_disp_snapshot_work. Correlate crashes with local diagnostic sessions, debugfs access, ADB activity, vendor maintenance tools, display subsystem errors, or repeated reboots. A single crash may be accidental driver instability; repeated crashes with the same stack trace, especially near user or diagnostic activity, should be investigated as possible intentional denial-of-service triggering.

• msm_disp_snapshot_add_block+
• msm_dsi_host_snapshot+
• msm_dsi_snapshot+
• msm_disp_snapshot_capture_state+
• msm_disp_snapshot_state_sync+
• _msm_disp_snapshot_work+
• drm/msm/dsi
• Unable to handle kernel paging request
• Internal error: Oops
• Kernel panic - not syncing
• pstore
• ramoops

What your security team should do

• Inventory Linux, Android, and embedded devices using Qualcomm MSM/DSI display hardware and prioritize DSI 6G-based platforms.
• Apply vendor kernel, firmware, or OS updates containing the MSM DSI bounds-check fix as they become available.
• Until patched, restrict local and diagnostic access that can trigger display snapshots or register dumps, including debugfs and vendor service interfaces.
• Monitor kernel logs, pstore, ramoops, crash dumps, and fleet reboot telemetry for MSM display snapshot stack traces.
• Treat repeated unexplained crashes with the listed MSM DSI functions as potential abuse or reliability-impacting fault conditions and preserve crash artifacts for analysis.
• Because the issue is not in KEV and has low EPSS, prioritize based on device criticality, physical/local access exposure, and operational impact rather than internet-facing risk.