CVE-2026-89867 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queued
Decoder instances sharing a VPU also share one v4l2_m2m job slot, released when the running context calls v4l2_m2m_job_finish(). While draining, device_run() defers job_finish() once EOS is sent (sent_eos), expecting a later finish_decode() (from a DEC_PIC completion IRQ) to release the slot.
But the m2m core checks job_ready() only when a job is queued, not when it is dispatched. A job queued while draining can run after finish_decode() has already moved the instance to STOP and sent EOS. device_run() then runs in STOP, issues no DEC_PIC, yet still skips job_finish() - so no IRQ, no finish_decode(), and the shared slot is leaked, stalling every instance. With several v4l2h264dec instances in parallel, GStreamer hangs at EOS.
Track whether the run actually queued a DEC_PIC (cmd_issued) and defer job_finish() only then. Otherwise finish the job immediately
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified within the Linux kernel's media subsystem specifically affects the chips-media wave5 video decoder driver, presenting a critical resource management flaw that leads to system stalling under concurrent workloads. This issue stems from an incorrect assumption regarding the lifecycle of hardware decoding jobs and their interaction with the V4L2 memory-to-memory framework. The underlying architecture relies on multiple decoder instances sharing a single Video Processing Unit (VPU) context, which is managed through a shared job slot within the v4l2_m2m core. This slot acts as a critical synchronization point, ensuring that only one decoding operation proceeds at any given time to prevent hardware conflicts and resource exhaustion. The integrity of this system depends on strict adherence to state transitions where the job slot is released precisely when the hardware processing completes via an interrupt request signaling the end of picture completion.
The technical flaw originates in the device_run function, which handles the execution context for decoding jobs. When a stream reaches its End Of Stream marker, indicated by the sent_eos flag, the driver attempts to drain remaining buffers and gracefully terminate the session. In this draining phase, the code incorrectly defers the call to v4l2_m2m_job_finish(), expecting that a subsequent hardware interrupt will trigger finish_decode() to release the shared slot. However, this logic fails to account for race conditions where new jobs are queued while the instance is in the process of stopping. The V4L2 m2m core only validates job readiness at the moment of queuing, not during dispatch or execution. Consequently, a newly queued job may execute after the previous context has already transitioned to the STOP state and signaled EOS. In this scenario, device_run executes within an invalid STOP state, issues no DEC_PIC command to the hardware, and consequently skips the deferred job_finish() call because it assumes a completion interrupt will follow.
This sequence of events results in a severe resource leak where the shared v4l2_m2m job slot is never released. Since the slot remains occupied by a stalled context that did not properly complete its hardware interaction, subsequent decoding instances are blocked from acquiring access to the VPU. This creates a deadlock condition within the media pipeline. The operational impact is most visible in complex multimedia applications such as GStreamer, where multiple parallel h264 decoder instances are common. When one instance encounters this state during EOS handling, it holds up the shared resource indefinitely, causing all other active decoders to hang and effectively freezing the entire video processing subsystem until a system reboot or manual process termination occurs.
To mitigate this vulnerability, the driver logic must be updated to accurately track whether a hardware command was actually issued before deferring job completion. By introducing a flag such as cmd_issued, the code can verify if a DEC_PIC command was successfully sent to the hardware during device_run(). If no command was issued, indicating that the context is terminating without active processing, v4l2_m2m_job_finish() should be called immediately rather than deferred. This ensures that the shared job slot is released promptly even in edge cases involving stream termination and concurrent queuing. From a security perspective, this flaw aligns with CWE-770: Allocation of Resources Without Limits or Throttling, as it allows a single instance to monopolize a critical system resource indefinitely due to improper state management. Furthermore, the exploitation vector relates to ATT&CK technique T1496: Resource Hijacking, where an attacker could potentially cause denial of service by triggering this race condition through carefully crafted media streams that force concurrent decoding and stream termination scenarios.