CVE-2026-89867
N/A
Summary
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
Affected Software
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | a176ac5e701f1ba30843c0d7e0663a761bf9a61a < 63d758d2f9dba836d5ae597d317cde522e817cf9 | affected |
| Linux | Linux | a176ac5e701f1ba30843c0d7e0663a761bf9a61a < b694ba0a5526a69f78a6924982b1553154ccfd73 | affected |
| Linux | Linux | 7.0 | affected |
| Linux | Linux | 0 < 7.0 | unaffected |
| Linux | Linux | 7.2.5 <= 7.2.* | unaffected |
| Linux | Linux | 7.3-rc1 <= * | unaffected |
Weaknesses
References
- https://git.kernel.org/stable/c/63d758d2f9dba836d5ae597d317cde522e817cf9
- https://git.kernel.org/stable/c/b694ba0a5526a69f78a6924982b1553154ccfd73
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.