CVE-2026-89866 in Linux
Summary
by MITRE • 09/16/2026
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 send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) 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 send_firmware_command+0x2c/0x160 [wave5]
wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5]
wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5]
wave5_vpu_dec_job_abort+0x44/0xa0 [wave5]
v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem]
v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem]
Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel media subsystem for chips-media wave5 drivers represents a critical race condition involving power management states and hardware register access. The core issue stems from an improper sequence of operations during device shutdown or stream termination, specifically when handling End-Of-Stream (EOS) flags. In this scenario, the driver attempts to communicate with the Video Processing Unit firmware by invoking send_firmware_command(), which necessitates direct interaction with VPU registers. However, these register accesses are executed without verifying whether the hardware is in an active power state or has been suspended due to runtime power management policies. This oversight leads to a situation where software commands target powered-down hardware components that are not ready to respond, triggering asynchronous System Error (SError) interrupts on the CPU.
From a technical perspective, this flaw manifests when either the STREAMOFF path via wave5_vpu_dec_job_abort() or the V4L2_DEC_CMD_STOP path through wave5_vpu_dec_stop() is triggered while the device remains in a runtime suspended state. The kernel stack traces indicate that these functions proceed to update bitstream buffers and set flags, ultimately calling into firmware command handlers that access physical memory-mapped I/O regions. Because the hardware clock or power domain has been gated off by the PM subsystem to save energy, any attempt to read from or write to those registers results in a bus error. On ARM-based systems, this typically generates an SError interrupt with codes such as 0x00000000bf000000, which is unhandled and fatal, causing the kernel to panic immediately rather than gracefully handling the hardware fault.
The operational impact of this vulnerability is severe, resulting in a complete system crash or denial of service for any process relying on the media subsystem. An attacker or even an automated power management daemon could potentially trigger this condition by initiating stream stops during periods of low activity when runtime PM might have already suspended the device. This affects not only local stability but also reliability in embedded systems where continuous operation is required, such as set-top boxes or industrial video processing units. The lack of proper synchronization between the V4L2 state machine and the runtime power management framework creates a window of vulnerability that can be exploited to destabilize the entire operating environment.
This issue aligns with CWE-367, Time-of-check Time-of-use (TOCTOU) race conditions, as there is a gap between checking or assuming device availability and actually accessing hardware resources without ensuring those resources remain active. Furthermore, it relates to CWE-258, Obfuscation of Critical Steps, in the sense that the power state transition logic was not adequately integrated into the command execution flow, leading to unexpected behavior under specific timing conditions. In terms of MITRE ATT&CK, this could be categorized under T1499: Endpoint Denial of Service, as it allows for local denial of service through resource exhaustion or system instability caused by improper hardware interaction patterns.
To mitigate this vulnerability, the driver implementation must enforce strict power management synchronization before any firmware command is sent to the VPU. The recommended fix involves wrapping the EOS flag setting operation with pm_runtime_resume_and_get() to ensure the device and its associated clocks are powered on and ready for communication. Following the successful execution of the firmware command, the system should call pm_runtime_put_autosuspend() to allow the power management core to manage subsequent suspension based on idle timeouts. This approach mirrors the existing runtime PM handling already present in wave5_vpu_dec_device_run(), ensuring consistency across all code paths that interact with the hardware registers. By aligning the shutdown and abort sequences with the active device lifecycle, the risk of accessing powered-down hardware is eliminated, preventing SError interrupts and maintaining system stability during stream termination events.