CVE-2026-90362

What it actually does

The flaw in the MSM DSI driver calls dev_pm_opp_set_rate(0) which removes a required-opps vote without parking the clock, allowing the clock to run without its necessary power domain backing before the subsequent pm_runtime_put call rescinds the vote.

Why it matters to the business

Linux-based devices using Qualcomm MSM graphics hardware may experience unexpected display or graphics subsystem instability due to improper power management sequencing.

How an attack unfolds

An attacker triggers the link_clk_disable path in the DSI driver (followed by runtime power put) to exercise the incorrect dev_pm_opp_set_rate(0) sequence, leaving the clock operating without power backing and potentially causing hardware-level misbehavior or crashes.

How to fix it

Apply the upstream kernel patch that removes the dev_pm_opp_set_rate(0) call from the DSI driver and ensure all call sites rely solely on pm_runtime_put for power vote management.

How to confirm the fix worked

Confirm the dev_pm_opp_set_rate(0) call has been removed from the msm dsi driver source, rebuild the kernel, and verify that link_clk_disable paths are followed only by pm_runtime_put without explicit rate-zero calls.

Typical attack path

1. Obtain local code execution or trigger DSI link clock disable path
2. Invoke ops->link_clk_disable()
3. Allow the subsequent pm_runtime_put() to execute
4. Observe clock continuing without power domain support

How to detect it

Inspect kernel logs for DSI driver warnings or clock/power domain errors around display initialization or runtime suspend; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel updates containing the dsi power management fix on all affected Linux systems
• Monitor vendor backports for embedded and Android devices using MSM DSI
• Review power management call sequences in downstream DRM drivers for similar patterns