CVE-2026-89867: media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queued

Published Sep 16, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

media: chips-media: wave5: Defer jobfinish() only when a DECPIC was queued

Decoder instances sharing a VPU also share one v4l2m2m job slot, released when the running context calls v4l2m2mjobfinish(). While draining, devicerun() defers jobfinish() once EOS is sent (senteos), expecting a later finishdecode() (from a DECPIC completion IRQ) to release the slot.

But the m2m core checks jobready() only when a job is queued, not when it is dispatched. A job queued while draining can run after finishdecode() has already moved the instance to STOP and sent EOS. devicerun() then runs in STOP, issues no DECPIC, yet still skips jobfinish() - so no IRQ, no finishdecode(), 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 DECPIC (cmdissued) and defer jobfinish() only then. Otherwise finish the job immediately

Event History

Sep 16, 2026
CVE Published
via MITRE·10:31 AM
Data Sourced
via MITRE·10:31 AM
Description

Frequently Asked Questions

1

What workload is most likely to trigger the stall?

The issue is described when several v4l2h264dec decoder instances run in parallel on a shared VPU. GStreamer can hang when those instances reach end-of-stream while draining.

2

What causes all decoder instances to become blocked?

A job can be dispatched after its decoder instance has already entered STOP and sent EOS. That run queues no DEC_PIC but defers completion anyway, leaving the shared v4l2_m2m job slot unreleased and stalling every instance sharing it.

3

How can I tell whether this issue is occurring?

Affected systems may hang at EOS during parallel GStreamer v4l2h264dec use. The observable failure is that all instances sharing the VPU stall after the shared m2m job slot is leaked.

4

What behavior resolves the issue?

The fix tracks whether the run actually issued a DEC_PIC command. Job completion is deferred only when a DEC_PIC was queued; otherwise the job is finished immediately so the shared slot is released.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203