CVE-2026-68209
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A bug in a Linux camera driver can leak memory when video streaming fails to start, potentially letting a local user destabilize the system.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Failure to return queued vb2 buffers via vb2_buffer_done() when sun4i_csi_start_streaming() returns -EINVAL on format mismatch causes owned_by_drv_count mismatch, triggering WARN_ON and leaking buffers that remain owned by the driver.
Why it matters to the business
Local processes can trigger kernel warnings and buffer leaks in the media subsystem, risking system instability, resource exhaustion, or escalation to memory corruption on affected Linux kernels.
How an attack unfolds
An attacker with local access opens a video device backed by sun4i-csi, queues buffers through the vb2 framework, then induces a CSI format mismatch so start_streaming fails before setup; the missing return path leaks the buffers and fires the warning, enabling further corruption or denial of service.
How to fix it
Update the Linux kernel to a version containing the referenced fix that redirects the early -EINVAL path to err_clear_dma_queue and calls return_all_buffers under the qlock.
How to confirm the fix worked
Confirm the patch is applied by inspecting sun4i_csi_start_streaming() for an unconditional jump to err_clear_dma_queue on format lookup failure; recompile and boot test with a deliberately mismatched format to verify no WARN_ON occurs.
Typical attack path
- Obtain local user or process execution on the target system
- Open /dev/video* node associated with sun4i-csi driver
- Queue capture buffers via VIDIOC_QBUF or equivalent
- Trigger start_streaming failure by supplying unsupported format
- Observe kernel WARN_ON and buffer ownership leak
How to detect it
Search kernel logs and dmesg for sun4i-csi or vb2_start_streaming WARN_ON messages referencing owned_by_drv_count; examine media device open/close sequences and any format negotiation failures preceding the warning.
What your security team should do
- Prioritize kernel updates on systems exposing video4linux devices
- Monitor kernel logs for sun4i-csi and vb2 WARN_ON(owned_by_drv_count) messages
- Restrict unprivileged access to /dev/video* nodes via udev or device groups until patched
The record
In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure").
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|