CVE-2026-89867 in Linux
Zusammenfassung
von VulDB • 16.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
media: chips-media: wave5: Job-Finish nur dann verschieben, wenn ein DEC_PIC in die Warteschlange gestellt wurde
Decoder-Instanzen, die sich eine VPU teilen, nutzen auch einen gemeinsamen v4l2_m2m-Job-Slot, der freigegeben wird, wenn der laufende Kontext `v4l2_m2m_job_finish()` aufruft. Während des Entleerungsprozesses (Draining) verschiebt `device_run()` den Aufruf von `job_finish()`, sobald EOS gesendet wurde (`sent_eos`), in Erwartung eines späteren `finish_decode()`-Aufrufs (aus einem DEC_PIC-Vervollständigungs-IRQ), der den Slot freigeben soll.
Das m2m-Core prüft jedoch `job_ready()` nur, wenn ein Job in die Warteschlange gestellt wird, nicht aber bei dessen Zustellung. Ein während des Entleerungsprozesses eingereichter Job kann nach dem Aufruf von `finish_decode()`, der die Instanz bereits auf STOP gesetzt und EOS gesendet hat, ausgeführt werden. Daraufhin läuft `device_run()` im Zustand STOP ab, gibt keinen DEC_PIC aus, überspringt jedoch dennoch den Aufruf von `job_finish()` – was dazu führt, dass kein IRQ ausgelöst wird, `finish_decode()` nicht aufgerufen wird und der gemeinsam genutzte Slot geleakt wird, wodurch jede Instanz blockiert wird. Bei mehreren parallel laufenden v4l2h264dec-Instanzen hängt GStreamer bei EOS.
Es ist nun zu verfolgen, ob die Ausführung tatsächlich einen DEC_PIC in die Warteschlange gestellt hat (`cmd_issued`), und `job_finish()` nur dann zu verschieben. Andernfalls ist der Job sofort abzuschließen.
If you want to get best quality of vulnerability data, you may have to visit VulDB.