A buffer leak in the sun4i-csi driver (CVE-2026-68209) exposes a structural flaw in how the vb2 video buffer framework handles streaming failures. When start_streaming() fails due to format validation or hardware errors, the driver must explicitly return all buffers it received from vb2 via vb2_buffer_done() — even if nothing was actually set up. The sun4i-csi driver failed to do this, leaking buffers on every failed stream start.
This is not a one-off mistake. The exact same bug existed in the uvcvideo driver and was fixed there first. The sun4i-csi commit message explicitly states 'This mirrors the uvcvideo fix.' That phrasing is the red flag: the kernel media subsystem has documented evidence of the same vulnerability pattern across drivers, has acknowledged it in version control, and has chosen per-driver patches rather than fixing the framework contract.
The vb2 framework hands buffers to the driver early — before start_streaming() runs — creating a state where the driver 'owns' those buffers in vb2's accounting even though nothing has been configured. A developer returning -EINVAL for a format mismatch is following logical semantics; returning buffers when nothing was allocated feels unnecessary. But vb2's contract requires it anyway, and the API does nothing to enforce or make this obvious. The result is a trap that catches competent developers who reason correctly about resource allocation but haven't memorized vb2's implicit state machine.
For defenders: audit every vb2-based driver in drivers/media/ for early return paths in start_streaming() that don't call vb2_buffer_done() on all dequeued buffers. The sun4i-csi fix jumps to an existing cleanup label (err_clear_dma_queue), which works because no hardware resources had actually been allocated at that point — the reasoning is sound but non-obvious. If you maintain a media driver, trace every early error return in start_streaming() and confirm vb2_buffer_done() was called for every buffer obtained via vb2_dequeue_buf().
The CVSS 7.8 score understates the real impact. These leaks accumulate deterministically on every failed stream start, leading to resource exhaustion that enables reliable local DoS against /dev/video* nodes. In camera pipelines processing adversarial input, this is a plausible first step in more complex exploit chains. The kernel added a WARN_ON in vb2_start_streaming() to catch this class of bug — but warnings document violations after they happen rather than preventing them. The subsystem maintainers have the pattern, the fix template, and years of evidence. What they haven't done is translate that knowledge into a framework-level enforcement that makes correct buffer return the only possible behavior.