Description
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
Metrics
No CVSS score has been published yet.
Affected software
Source: the vendor's advisory (CNA). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux | >= a176ac5e701f1ba30843c0d7e0663a761bf9a61a, < 63d758d2f9dba836d5ae597d317cde522e817cf9; >= a176ac5e701f1ba30843c0d7e0663a761bf9a61a, < b694ba0a5526a69f78a6924982b1553154ccfd73 |
| Linux | Linux | 7.0 |
References
Timeline
- Published
- Sep 16, 2026
- Last modified
- Oct 19, 2026
- NVD status
- Received