Cloudanix VulnDB

CVE-2026-68204

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in a Linux kernel component that handles virtual video devices could let a logged-in user cause crashes or gain higher privileges by changing settings at the wrong time.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Missing vb2_is_busy() checks in vivid_update_format_cap/out() allow format capability changes (CROP/COMPOSE/SCALE) on busy queues between REQBUFS and STREAMON, resulting in inconsistent state and potential memory corruption or unexpected driver behavior.

Why it matters to the business

Systems relying on the vivid virtual media driver for testing or capture may experience kernel instability, crashes, or local privilege escalation, disrupting media workflows and requiring urgent patching on affected Linux kernels.

How an attack unfolds

An attacker with local access issues ioctls to toggle crop/compose/scale controls while queues are in a transitional state after REQBUFS but before STREAMON; this bypasses the intended locking and triggers vivid_update_format_cap/out() without the busy check, leading to format changes that corrupt state when streaming later begins.

How to fix it

Apply the upstream fix that adds vb2_is_busy() guards and WARN_ON assertions in vivid_update_format_cap/out(); rebuild and deploy the patched kernel; disable the vivid module if virtual media testing is not required.

How to confirm the fix worked

Verify the presence of the busy-queue checks and WARN_ON statements in vivid_update_format_cap and vivid_update_format_out after patching; confirm the module loads without the syzbot-reported inconsistent state under concurrent control and streaming ioctls.

Typical attack path

  1. Obtain local user access on a system with the vivid driver loaded
  2. Open the vivid device and issue VIDIOC_REQBUFS to allocate buffers without starting streaming
  3. Toggle CROP/COMPOSE/SCALE controls via VIDIOC_S_CTRL to invoke the unchecked update paths
  4. Issue VIDIOC_STREAMON to activate the now-inconsistent queue state
  5. Trigger use of the corrupted format state to achieve denial of service or escalation

How to detect it

Review kernel logs for WARN_ON triggers inside vivid_update_format_cap or vivid_update_format_out; monitor for unusual sequences of VIDIOC_REQBUFS followed immediately by control changes and STREAMON on /dev/video* nodes.

What your security team should do

  • Prioritize kernel update on all systems exposing the vivid driver within the next 30 days
  • Audit for custom or downstream kernels that may have backported vivid changes
  • Consider blacklisting the vivid module via modprobe.d unless explicitly needed for development

The record

In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.

Affected packages

Ecosystem Package Introduced Fixed