CVE-2026-89866: media: chips-media: wave5: Resume device before setting EOS flag
In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Resume device before setting EOS flag
Setting the EOS flag talks to the firmware via sendfirmwarecommand(), which accesses VPU registers. Both the STREAMOFF path (wave5vpudecjobabort()) and the V4L2DECCMDSTOP path (wave5vpudecstop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel:
SError Interrupt on CPU3, code 0x00000000bf000000 -- SError sendfirmwarecommand+0x2c/0x160 [wave5] wave5vpudecsetbitstreamflag+0x6c/0x80 [wave5] wave5vpudecupdatebitstreambuffer+0x80/0xec [wave5] wave5vpudecjobabort+0x44/0xa0 [wave5] v4l2m2mcanceljob+0x110/0x19c [v4l2mem2mem] v4l2m2mstreamoff+0x24/0x140 [v4l2mem2mem]
Resume the device with pmruntimeresumeandget() around the EOS firmware command and release it with pmruntimeputautosuspend(), matching the runtime PM handling already done in wave5vpudecdevicerun().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch media: chips-media: wave5: Resume device before setting EOS flag - Operational
Resume the device with pm_runtime_resume_and_get() around the EOS flag handling, then release it with pm_runtime_put_autosuspend() after send_firmware_command() completes (around EOS SError-triggering firmware command).
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel Wave5 media driver are exposed when the affected decoder paths can execute while the VPU device is runtime suspended. The issue is associated with STREAMOFF handling and the V4L2 decoder STOP command.
What triggers the kernel failure?
A local workload that stops a Wave5 decoder stream can cause the driver to set an EOS flag while the device is suspended. That operation sends a firmware command that accesses powered-down VPU registers, which can raise an asynchronous SError and panic the kernel.
What is the practical impact?
The documented impact is a kernel panic caused by an asynchronous SError. This is therefore a denial-of-service condition for the affected host.
What does the fix change?
The fix resumes the device with pm_runtime_resume_and_get() before sending the EOS firmware command, then releases it with pm_runtime_put_autosuspend(). This ensures register access occurs only while the VPU is powered.