CVE-2026-68204: Linux Kernel Privilege Escalation Flaw

CVE-2026-68204 Overview

CVE-2026-68204 affects the Linux kernel vivid virtual video driver in the media subsystem. The vulnerability stems from missing vb2_is_busy() checks when toggling CROP, COMPOSE, and SCALE capability controls. Between REQBUFS and STREAMON operations, a local user can modify these controls even though the buffer queue is already allocated. This triggers vivid_update_format_cap/out() and changes the format while buffers exist, producing an inconsistent state. Kernel maintainers link this defect to a syzbot-reported crash. The flaw impacts confidentiality, integrity, and availability on affected local systems.

Critical Impact
Local attackers with access to the vivid device can trigger inconsistent kernel state, leading to potential memory corruption and denial of service.

Affected Products

Linux kernel media subsystem, vivid driver (drivers/media/test-drivers/vivid)
Multiple stable kernel branches (see referenced commits)
Systems where the vivid module is loaded and accessible to local users

Discovery Timeline

2026-08-10 - CVE-2026-68204 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68204

Vulnerability Analysis

The vivid driver exposes Video4Linux2 (V4L2) controls that select CROP, COMPOSE, and SCALE capabilities. Setting these controls calls vivid_update_format_cap() or vivid_update_format_out(), which mutate the active pixel format. Those helpers assume the capture or output queue is idle. The driver only marks the controls as grabbed once streaming starts through STREAMON. Between REQBUFS (which allocates buffers) and STREAMON, the controls remain writable while buffers already reflect an assumed format. A local user can change the format underneath the allocated buffers, producing a mismatch between buffer metadata and the driver's format state. The maintainer attributes a syzbot-reported crash (extid=dac8f5eaa46837e97b89) to this window.

Root Cause

The root cause is a missing precondition check in the control s_ctrl handlers. The code path does not call vb2_is_busy() before invoking vivid_update_format_cap/out(). This is a state validation defect where the driver trusts that streaming state alone gates format changes, ignoring the intermediate REQBUFS state.

Attack Vector

Exploitation requires local access and permission to open the vivid/dev/video* node. An attacker calls VIDIOC_REQBUFS to allocate buffers, then issues VIDIOC_S_CTRL against the CROP, COMPOSE, or SCALE capability controls before calling VIDIOC_STREAMON. The driver updates the format while buffers exist in an inconsistent state, which can lead to memory safety violations inside the videobuf2 layer. No user interaction beyond the local process is required.

No verified public exploit code is available. See the referenced upstream commits for the fix details: Linux Kernel Commit 492c97c and Linux Kernel Commit daf2d926.

Detection Methods for CVE-2026-68204

Indicators of Compromise

Kernel WARN_ON splats originating from vivid_update_format_cap() or vivid_update_format_out() in dmesg
Unexpected V4L2 VIDIOC_S_CTRL calls issued between VIDIOC_REQBUFS and VIDIOC_STREAMON on /dev/video* nodes exposed by the vivid module
Kernel oops or general protection fault stack traces referencing videobuf2 or vivid symbols

Detection Strategies

Audit loaded kernel modules for the presence of vivid on production hosts, since it is a test driver not required in most deployments
Monitor auditd for ioctl sequences on /dev/video* devices originating from non-privileged processes
Correlate kernel log warnings with process telemetry to identify the invoking user and binary

Monitoring Recommendations

Forward kernel logs (journald, rsyslog) to a centralized data lake and alert on WARN_ON, BUG:, or KASAN: entries referencing vivid or vb2_
Track modprobe/insmod events for the vivid module across the fleet
Baseline expected users of V4L2 devices and flag deviations for review

How to Mitigate CVE-2026-68204

Immediate Actions Required

Unload the vivid module on production systems where it is not required using modprobe -r vivid
Blacklist the module by adding blacklist vivid under /etc/modprobe.d/ to prevent auto-load
Restrict access to /dev/video* device nodes to trusted users and groups only
Apply the upstream kernel patches once your distribution publishes updated packages

Patch Information

The fix adds vb2_is_busy() checks in the CROP, COMPOSE, and SCALE control handlers, and adds a WARN_ON in vivid_update_format_cap/out() when the queue is busy. Patches are available in the following upstream commits: Linux Kernel Commit 492c97c, Linux Kernel Commit a9cd0e8f, Linux Kernel Commit abaec674, Linux Kernel Commit c2d1a213, and Linux Kernel Commit daf2d926.

Workarounds

Disable the vivid driver in kernel configuration (CONFIG_VIDEO_VIVID=n) when rebuilding kernels
Enforce filesystem permissions on /dev/video* to exclude untrusted local accounts
Apply Mandatory Access Control policies (SELinux, AppArmor) that limit V4L2 ioctl access to specific applications

bash

# Prevent the vivid test driver from loading
echo 'blacklist vivid' | sudo tee /etc/modprobe.d/disable-vivid.conf
sudo modprobe -r vivid 2>/dev/null || true

# Verify the module is not loaded
lsmod | grep -i vivid