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).
References
- https://git.kernel.org/stable/c/4872161e6fbe4e1783daea8bff79caddfae0fb82
- https://git.kernel.org/stable/c/668face37fdb6b6900645dc8777195498541c9a7
- https://git.kernel.org/stable/c/a8abecc638a7feb20b78fabd563b05e30c071331
- https://git.kernel.org/stable/c/b5184b3f0e9d4cc47059ba1138c9a73d43d2493f
- https://git.kernel.org/stable/c/bbba3e260a62810a717b4442a3bb96d0ec0f6309