{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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",
  "id": "DEBIAN-CVE-2026-89867",
  "modified": "2026-09-17T04:47:37.670052305Z",
  "published": "2026-09-16T11:16:54.843Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-89867"
    }
  ],
  "upstream": [
    "CVE-2026-89867"
  ]
}