{"id":"CVE-2026-89867","published":"2026-09-16T11:16:54.843","lastModified":"2026-09-16T11:16:54.843","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queued\n\nDecoder instances sharing a VPU also share one v4l2_m2m job slot, released\nwhen the running context calls v4l2_m2m_job_finish(). While draining,\ndevice_run() defers job_finish() once EOS is sent (sent_eos), expecting a\nlater finish_decode() (from a DEC_PIC completion IRQ) to release the slot.\n\nBut the m2m core checks job_ready() only when a job is queued, not when it\nis dispatched. A job queued while draining can run after finish_decode()\nhas already moved the instance to STOP and sent EOS. device_run() then runs\nin STOP, issues no DEC_PIC, yet still skips job_finish() - so no IRQ, no\nfinish_decode(), and the shared slot is leaked, stalling every instance.\nWith several v4l2h264dec instances in parallel, GStreamer hangs at EOS.\n\nTrack whether the run actually queued a DEC_PIC (cmd_issued) and defer\njob_finish() only then. Otherwise finish the job immediately","cvssScore":null,"cvssSeverity":null,"cvssVector":null,"cwes":[],"vendors":[],"products":[],"references":[{"url":"https://git.kernel.org/stable/c/63d758d2f9dba836d5ae597d317cde522e817cf9","tags":[]},{"url":"https://git.kernel.org/stable/c/b694ba0a5526a69f78a6924982b1553154ccfd73","tags":[]}],"exploitRefs":[],"hasPoc":false,"ai":null}