CVE-2026-43290: Linux Kernel UVC Video DOS Vulnerability

CVE-2026-43290 Overview

CVE-2026-43290 affects the Linux kernel's USB Video Class (UVC) driver (uvcvideo). The flaw resides in the start_streaming() path, where queued video buffers are not returned to the videobuf2 framework when uvc_pm_get() fails. This bug surfaces during error handling when streaming initialization aborts, leaving buffers in an inconsistent state. The issue has been observed under repeated stream start/stop workloads, particularly on xHCI controllers that drop the device mid-operation.

Critical Impact
Local users with access to a UVC video device can trigger resource handling errors in the kernel through repeated streaming attempts, potentially impacting kernel stability and integrity.

Affected Products

Linux Kernel (uvcvideo driver, drivers/media/usb/uvc/)
Systems using USB Video Class devices (webcams, capture devices)
xHCI host controllers exercising the affected code paths

Discovery Timeline

2026-05-08 - CVE-2026-43290 published to NVD
2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-43290

Vulnerability Analysis

The vulnerability affects the Linux kernel uvcvideo driver, which implements the V4L2 streaming interface for USB Video Class devices. When user space initiates streaming on a UVC device, the driver calls start_streaming(), which in turn invokes uvc_pm_get() to acquire a power management reference before activating the stream.

If uvc_pm_get() returns an error, start_streaming() aborts without returning the buffers that have already been queued through videobuf2-core. The videobuf2 framework expects the driver to return queued buffers to the VB2_BUF_STATE_QUEUED state when streaming fails to start. Failure to do so leaves buffers owned by the driver while the framework considers them returnable.

This inconsistency triggers a WARN at drivers/media/common/videobuf2/videobuf2-core.c:1803 in vb2_start_streaming(). The reporter observed the warning during stress testing with yavta -c3 /dev/video0 on an xHCI controller that experienced a host controller death (HC died; cleaning up).

Root Cause

The root cause is missing error path cleanup [CWE-noinfo]. The start_streaming() callback in the uvcvideo driver does not release ownership of queued videobuf2 buffers when uvc_pm_get() fails. The fix returns buffered frames to the videobuf2 core on the failure path, restoring the state contract between driver and framework.

Attack Vector

The attack vector is local and requires the attacker to have permission to open the V4L2 device node (typically /dev/video0). An attacker with local access who can interact with a UVC device under conditions that cause uvc_pm_get() to fail (such as a disconnecting or unstable USB host controller) can drive the kernel into the inconsistent buffer state. Exploitation depends on hardware error conditions, limiting practical reach, but the issue can produce kernel warnings and impact confidentiality, integrity, and availability of the host.

No public exploit is available, and the EPSS score indicates very low predicted exploitation likelihood. See the upstream commits referenced below for the fix.

Detection Methods for CVE-2026-43290

Indicators of Compromise

Kernel log entries containing WARNING: CPU: ... at drivers/media/common/videobuf2/videobuf2-core.c:1803 vb2_start_streaming
Repeated xhci_hcd ... HC died; cleaning up messages preceding UVC streaming failures
Unexpected USB disconnect events correlated with V4L2 streaming attempts on UVC devices

Detection Strategies

Monitor dmesg and journalctl -k for vb2_start_streaming warnings tied to uvcvideo
Audit running kernel versions across endpoints to identify hosts that have not received the upstream stable fixes
Correlate USB host controller errors with V4L2 streaming activity in centralized logs

Monitoring Recommendations

Forward kernel ring buffer events to a centralized logging or SIEM platform for long-term retention
Alert on kernel WARNING or BUG entries originating from videobuf2-core or uvcvideo modules
Track USB device enumeration churn on workstations and capture-card hosts where UVC devices are exercised programmatically

How to Mitigate CVE-2026-43290

Immediate Actions Required

Apply the upstream stable kernel patches referenced in the vendor advisories before redeploying affected hosts
Inventory systems using UVC capture devices (conferencing endpoints, kiosks, capture appliances) and prioritize them for patching
Restrict access to /dev/video* device nodes to trusted users and groups using udev rules and filesystem permissions

Patch Information

The fix has been merged into the Linux stable trees. Apply the kernel update that includes one of the following commits: Kernel Git Commit 4cf3b6f, Kernel Git Commit 69c32df, and Kernel Git Commit a5c01f1. The patch modifies the uvcvideo driver to return queued buffers when start_streaming() fails because of a uvc_pm_get() error.

Workarounds

Blacklist the uvcvideo module on systems that do not require USB video functionality using /etc/modprobe.d/
Limit user permissions on V4L2 device nodes so only authorized service accounts can open UVC devices
Replace or reseat unstable USB host controllers exhibiting HC died errors, which act as the trigger condition

bash

# Configuration example
# Disable uvcvideo on hosts that do not need USB video
echo 'blacklist uvcvideo' | sudo tee /etc/modprobe.d/disable-uvcvideo.conf
sudo modprobe -r uvcvideo

# Restrict access to V4L2 device nodes via udev
echo 'KERNEL=="video[0-9]*", GROUP="video", MODE="0660"' | \
  sudo tee /etc/udev/rules.d/99-v4l2-restrict.rules
sudo udevadm control --reload-rules && sudo udevadm trigger