CVE-2026-89869: media: qcom: iris: use disable_irq() during power-off
In the Linux kernel, the following vulnerability has been resolved:
media: qcom: iris: use disableirq() during power-off
The IRQ is registered as a threaded IRQ.
Using disableirqnosync() in irisvpupoweroff() does not wait for an already queued threaded IRQ handler to complete before returning.
As a result, a threaded IRQ handler may still run after the VPU has been powered down and access hardware registers after power-off.
Replace disableirqnosync() with disableirq() so the power-off path waits for any in-flight threaded IRQ handler to complete before returning.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In iris_vpu_power_off(), replace disable_irq_nosync() with disable_irq() so the power-off path waits for an already queued threaded IRQ handler to complete before powering down and accessing hardware registers.
Linux kernel (media: qcom: iris) disable_irq_nosync() -> disable_irq() = disable_irq()
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The affected power-off path must run while a threaded IRQ handler has already been queued or is still in flight. The race occurs because the previous non-synchronous IRQ disable operation could return before that handler completed.
What is the practical impact of the race?
A threaded IRQ handler can execute after the VPU has been powered down and attempt to access hardware registers. The provided data does not describe a privilege boundary, remote attack vector, or specific user-visible outcome.
How does the fix prevent the problem?
The fix replaces disable_irq_nosync() with disable_irq() during VPU power-off. disable_irq() waits for any in-flight threaded IRQ handler to finish before the power-off path returns.