CVE-2026-68213

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rtl2832_sdr: Return queued buffers on start_streaming() failure<br /> <br /> The vb2 framework hands buffers to the driver via buf_queue() before<br /> calling start_streaming(). If start_streaming() returns an error<br /> without first returning those buffers via vb2_buffer_done(),<br /> vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued<br /> buffers leak.<br /> <br /> rtl2832_sdr_start_streaming() had multiple error paths that hit this<br /> trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six<br /> `goto err` paths covering subdev s_power, tuner setup, ADC setup,<br /> stream-buffer allocation, urb allocation, and urb submission failures.<br /> None of them returned the queued buffers.<br /> <br /> The original function had no distinct success exit and fell straight<br /> through into the err label, which previously only did mutex_unlock and<br /> "return ret". Adding queued-buffer cleanup at err must therefore be<br /> paired with an explicit success return; otherwise every successful<br /> start would also drain the buffer queue and kill streaming. Add that<br /> success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err<br /> label and before each early return.<br /> <br /> The cleanup helper takes a vb2_buffer_state argument so that the<br /> start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as<br /> expected by userspace on start_streaming failure) while stop_streaming<br /> keeps its existing VB2_BUF_STATE_ERROR semantics.<br /> <br /> This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:<br /> Return queued buffers on start_streaming() failure").<br /> <br /> The err label still does not roll back power_ctrl(), frontend_ctrl(),<br /> the POWER_ON flag, or stream/URB allocations that may have happened<br /> before the failing step. Those are pre-existing leaks of a different<br /> class and are not addressed here.