CVE-2026-89866: Linux Kernel Wave5 Driver Privilege Escalation

CVE-2026-89866 Overview

CVE-2026-89866 is a Linux kernel vulnerability in the Chips&Media Wave5 video processing unit (VPU) driver (drivers/media/platform/chips-media/wave5). The driver sends an end-of-stream (EOS) firmware command that touches VPU registers while the device may be runtime-suspended. Accessing powered-down hardware triggers an asynchronous System Error (SError) interrupt, which panics the kernel. The flaw affects both the STREAMOFF path in wave5_vpu_dec_job_abort() and the V4L2_DEC_CMD_STOP path in wave5_vpu_dec_stop(). The upstream fix resumes the device before issuing the firmware command.

Critical Impact
A local user issuing standard V4L2 decoder ioctls on affected SoCs can force MMIO access to a runtime-suspended VPU, producing an SError and a full kernel panic (denial of service).

Affected Products

Linux kernel builds including the wave5 chips-media decoder driver
SoC platforms integrating the Chips&Media Wave5 VPU with runtime power management
Distributions shipping the affected driver prior to the fix commits 2215e55e and a52e6f79

Discovery Timeline

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

Technical Details for CVE-2026-89866

Vulnerability Analysis

The Wave5 decoder driver exposes standard V4L2 memory-to-memory operations. When userspace calls VIDIOC_STREAMOFF or issues V4L2_DEC_CMD_STOP, the driver marks the bitstream buffer with an EOS flag by calling wave5_vpu_dec_set_bitstream_flag(), which in turn invokes send_firmware_command(). That helper writes to VPU MMIO registers to notify the on-chip firmware.

These code paths do not coordinate with runtime power management. If the VPU has already been runtime-suspended by the PM core, its clocks and power domain are gated. Register writes to a gated device on ARM64 SoCs generate an asynchronous SError, which the kernel treats as unrecoverable and panics. The reported call chain shows the fault originating in send_firmware_command+0x2c/0x160 reached via v4l2_m2m_streamoff and v4l2_m2m_cancel_job.

Root Cause

The root cause is a missing runtime PM reference around firmware command submission. The device_run path already wraps hardware access with pm_runtime_resume_and_get() and pm_runtime_put_autosuspend(), but the abort and stop paths did not. This is a kernel driver flaw involving improper hardware state management rather than a memory-safety bug.

Attack Vector

Exploitation requires local access to the V4L2 decoder device node (typically /dev/videoN). An unprivileged user with permission to open the decoder can trigger the panic by starting a decode session, then issuing VIDIOC_STREAMOFF or V4L2_DEC_CMD_STOP after the VPU has autosuspended. The impact is denial of service through kernel panic. No code execution or privilege escalation is indicated.

No verified exploit code is public. The upstream commits 2215e55e and a52e6f79 contain the corrective changes.

Detection Methods for CVE-2026-89866

Indicators of Compromise

Kernel log entries containing SError Interrupt on CPU with code 0x00000000bf000000 on systems using the wave5 driver.
Panic backtraces referencing send_firmware_command, wave5_vpu_dec_set_bitstream_flag, wave5_vpu_dec_update_bitstream_buffer, or wave5_vpu_dec_job_abort.
Unexpected reboots or watchdog resets correlated with V4L2 decoder STREAMOFF or V4L2_DEC_CMD_STOP activity.

Detection Strategies

Inventory kernel builds and identify whether the wave5 module is loaded (lsmod | grep wave5) and compare kernel versions against the fix commits.
Aggregate dmesg and pstore crash artifacts centrally and alert on the specific SError signature above.
Monitor host uptime anomalies on SoC platforms that ship the Wave5 VPU, especially those running media transcoding workloads.

Monitoring Recommendations

Forward kernel ring buffer and crash dumps into a centralized logging or SIEM tier for correlation across fleets.
Track V4L2 device access patterns on multi-tenant edge devices to identify processes issuing repeated STREAMOFF calls.
Alert when the same host produces multiple panics referencing the wave5 module within a short window.

How to Mitigate CVE-2026-89866

Immediate Actions Required

Apply upstream kernel commits 2215e55e and a52e6f79, or update to a stable kernel that includes them.
On affected devices, restrict access to /dev/videoN decoder nodes to trusted users and services via udev rules and group permissions.
Prioritize patch rollout on edge and embedded ARM64 platforms exposing V4L2 devices to untrusted workloads.

Patch Information

The fix wraps EOS firmware command submission with pm_runtime_resume_and_get() before the call and pm_runtime_put_autosuspend() after it, mirroring the runtime PM sequence already used in wave5_vpu_dec_device_run(). This ensures the VPU is powered and clocked before any MMIO access. Distribution kernels should backport both referenced commits together.

Workarounds

Disable runtime PM autosuspend for the Wave5 VPU device via sysfs so the hardware remains powered during decode sessions, accepting the increased power draw.
Unload the wave5 module on systems that do not require hardware video decoding.
Constrain decoder device permissions so only vetted media services can invoke STREAMOFF or V4L2_DEC_CMD_STOP.

bash

# Disable runtime PM autosuspend on the Wave5 VPU (path varies by SoC)
echo on | sudo tee /sys/bus/platform/devices/<wave5-device>/power/control

# Verify the wave5 module status
lsmod | grep wave5
uname -r