CVE-2026-68211: Linux Kernel Information Disclosure Bug

CVE-2026-68211 Overview

CVE-2026-68211 is a resource management flaw in the Linux kernel's STM32 Digital Camera Memory Interface Pixel Processor (stm32-dcmipp) media driver. The dcmipp_bytecap_start_streaming() function returned -EINVAL without returning buffers that the vb2 framework had already queued via buf_queue(). This caused vb2_start_streaming() to trigger a WARN_ON(owned_by_drv_count) and leak the queued buffers. The upstream fix redirects the early error path to the err_buffer_done label so dcmipp_bytecap_all_buffers_done() returns buffers with VB2_BUF_STATE_QUEUED. The fix mirrors an earlier uvcvideo correction in commit 4cf3b6fd54eb.

Critical Impact
Local users on affected STM32-based Linux systems can trigger kernel warnings and video buffer leaks when the DCMIPP source subdevice cannot be resolved from the media graph.

Affected Products

Linux kernel builds including the stm32-dcmipp media driver
STMicroelectronics STM32 platforms using the DCMIPP capture pipeline
Downstream distributions shipping affected kernel versions prior to the referenced stable commits

Discovery Timeline

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

Technical Details for CVE-2026-68211

Vulnerability Analysis

The vb2 (videobuf2) framework passes buffers to media drivers through buf_queue() before invoking start_streaming(). Drivers must return those buffers to vb2 if streaming initialization fails. Failing to do so leaves buffers marked as owned by the driver.

In the vulnerable code, dcmipp_bytecap_start_streaming() returned -EINVAL directly when the source subdevice could not be resolved from the media graph. This early return happened before pm_runtime_resume_and_get() and media_pipeline_start() were called and before any buffers were released. The framework then triggered WARN_ON(owned_by_drv_count) inside vb2_start_streaming(), and the queued buffers leaked.

Root Cause

The root cause is an incomplete error path in the driver's streaming initialization logic. The function did not converge on the existing err_buffer_done label that invokes dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED) to return buffers to the framework. Instead, it exited without releasing driver ownership of queued buffers, breaking the vb2 contract.

Attack Vector

A local user with access to the DCMIPP capture device can trigger the flaw by initiating streaming when the media graph cannot resolve the source subdevice. Each failed attempt generates a kernel warning and leaks buffer state. Repeated triggering degrades video subsystem reliability and produces noisy kernel logs that can mask other events.

See the upstream fixes in commit 624af2d4, commit ed342a86, and commit ffc8eec0 for the code-level correction.

Detection Methods for CVE-2026-68211

Indicators of Compromise

Kernel log entries containing WARN_ON messages originating from vb2_start_streaming() on systems with the stm32-dcmipp driver loaded
Repeated -EINVAL return codes from dcmipp_bytecap_start_streaming() in dmesg output
Growing owned_by_drv_count counters correlated with failed streaming attempts

Detection Strategies

Audit installed kernel versions against the fixed stable commits referenced in the NVD entry
Monitor kernel ring buffer output for warnings tied to the DCMIPP capture path
Correlate media pipeline start failures with buffer accounting anomalies in /sys/kernel/debug/

Monitoring Recommendations

Forward dmesg and journalctl -k output to a centralized logging pipeline for kernel warning analysis
Alert on repeated WARN_ON events from drivers/media/ code paths
Track uptime and reboot metrics for embedded STM32 devices exposed to untrusted local users

How to Mitigate CVE-2026-68211

Immediate Actions Required

Update the Linux kernel to a version that includes commits 624af2d4, ed342a86, or ffc8eec0
Restrict local access to the DCMIPP /dev/video* device nodes to trusted users and groups
Rebuild custom or embedded kernels shipping the stm32-dcmipp driver with the upstream patch applied

Patch Information

The upstream fix redirects the early-return path in dcmipp_bytecap_start_streaming() to the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED) to return queued buffers to the vb2 framework. Skipping the err_pm_put and err_media_pipeline_stop labels is correct because neither pm_runtime_resume_and_get() nor media_pipeline_start() has run yet. Apply the patches referenced in the NVD entry: 624af2d4, ed342a86, and ffc8eec0.

Workarounds

Disable or unload the stm32-dcmipp kernel module on systems that do not require DCMIPP capture functionality
Validate media graph configuration through media-ctl before initiating streaming to avoid triggering the failure path
Apply strict udev rules limiting who can open the affected V4L2 device nodes

bash

# Configuration example: restrict access and block the vulnerable module until patched
echo 'blacklist stm32-dcmipp' | sudo tee /etc/modprobe.d/blacklist-stm32-dcmipp.conf
sudo chmod 660 /dev/video0
sudo chown root:video /dev/video0