CVE-2026-89867: Linux Kernel Wave5 Media Driver DoS Flaw

CVE-2026-89867 Overview

CVE-2026-89867 is a resource management flaw in the Linux kernel's chips-media wave5 Video Processing Unit (VPU) driver. Decoder instances sharing a VPU also share a single v4l2_m2m job slot. Under specific draining conditions, the driver skips the required v4l2_m2m_job_finish() call, leaking the shared slot and stalling every decoder instance on the device. GStreamer pipelines running multiple parallel v4l2h264dec instances hang at end-of-stream (EOS) as a result. The issue is a functional denial of service against media decoding rather than a memory safety flaw.

Critical Impact
A leaked shared v4l2_m2m job slot in the wave5 VPU driver stalls all decoder instances, causing multi-instance H.264 decode pipelines to hang indefinitely at EOS.

Affected Products

Linux kernel media: chips-media: wave5 decoder driver
Systems using shared wave5 VPU with multiple concurrent V4L2 M2M decoder contexts
Userspace stacks such as GStreamer running parallel v4l2h264dec instances

Discovery Timeline

2026-09-16 - CVE-2026-89867 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89867

Vulnerability Analysis

The wave5 driver serializes decoder work through a single v4l2_m2m job slot shared by all instances bound to the VPU. The running context is expected to release the slot by calling v4l2_m2m_job_finish(). During draining, device_run() deferred that call once EOS was sent, on the assumption that a later finish_decode() triggered by a DEC_PIC completion interrupt would release the slot.

That assumption breaks when the m2m core dispatches a job queued during drain. The m2m core evaluates job_ready() only at queue time, not at dispatch time. A job queued while the instance was still draining could be dispatched after finish_decode() had already transitioned the instance to STOP and emitted EOS. device_run() then executes in the STOP state, issues no DEC_PIC command, and still skips job_finish(). No completion interrupt fires, finish_decode() never runs, and the shared slot is leaked.

Root Cause

The root cause is a state-tracking flaw: device_run() deferred v4l2_m2m_job_finish() based solely on the sent_eos flag rather than on whether the current run actually queued a DEC_PIC command. When a run in STOP state issued no DEC_PIC, the deferred finish became unreachable, producing a race between drain completion and job dispatch [CWE-362 class behavior].

Attack Vector

The flaw is triggered by legitimate userspace media workloads, not a remote attacker. A local process opening multiple V4L2 decoder instances against the same wave5 VPU and driving them to EOS concurrently can reproduce the stall. The impact is a driver-level denial of service that halts subsequent decode work on the affected VPU until the module or system is reset.

See the fix commits for technical details: kernel commit 63d758d2f9db and kernel commit b694ba0a5526.

Detection Methods for CVE-2026-89867

Indicators of Compromise

Multiple v4l2h264dec or equivalent M2M decoder instances stuck in STOP state with no progress on /dev/videoN associated with a wave5 VPU.
GStreamer pipelines hanging at EOS when running several parallel H.264 decode sessions on the same chips-media wave5 device.
Absence of expected DEC_PIC completion interrupts on the VPU IRQ line while decoder instances remain queued.

Detection Strategies

Inventory kernels shipping the wave5 driver and correlate with running kernel versions that predate the referenced fix commits.
Instrument userspace decode pipelines to log EOS handling latency, treating unbounded waits as a signal of the slot-leak condition.
Use ftrace or perf on v4l2_m2m_job_finish, device_run, and finish_decode to observe missing finish events after EOS.

Monitoring Recommendations

Alert on media services (for example GStreamer-based transcoders) that stop producing frames while holding open V4L2 file descriptors.
Track kernel log entries from the wave5 driver for repeated sent_eos transitions without corresponding DEC_PIC completions.
Monitor CPU wait states on decode worker threads to detect indefinite blocking on the shared job slot.

How to Mitigate CVE-2026-89867

Immediate Actions Required

Apply the upstream fixes referenced in the stable tree commits 63d758d2f9db and b694ba0a5526 to affected kernels.
Rebuild and redeploy vendor kernels that carry the wave5 driver, prioritizing embedded and media appliance images.
Restart affected decode services after patching to clear any stalled v4l2_m2m contexts.

Patch Information

The fix introduces a cmd_issued state that records whether the current device_run() actually queued a DEC_PIC. v4l2_m2m_job_finish() is deferred only when cmd_issued is true. In all other cases, including runs dispatched after transition to STOP, the job is finished immediately, preventing the shared slot leak. Refer to the two kernel git commits linked above for the exact source changes.

Workarounds

Limit concurrent V4L2 decoder instances on a shared wave5 VPU to one until the patch is deployed.
Avoid pipelines that trigger drain and requeue in rapid succession on the same VPU, since the race requires a job queued during drain.
Reload the wave5 kernel module or reset the device when stalls are detected to temporarily restore decode capability.

bash

# Configuration example: temporarily unload and reload wave5 to clear a stalled slot
sudo systemctl stop media-decode.service
sudo modprobe -r wave5
sudo modprobe wave5
sudo systemctl start media-decode.service