CVE-2026-68222

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: msi2500: 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 /> msi2500_start_streaming() had five error paths that all hit this trap<br /> and were further tangled by ret-overwriting between calls:<br /> <br /> - -ENODEV when the USB device was already disconnected<br /> - -ERESTARTSYS when mutex_lock_interruptible() was interrupted<br /> - msi2500_set_usb_adc() failure: ret was silently overwritten by<br /> the next call (msi2500_isoc_init), so the error was lost entirely<br /> - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but<br /> the function then fell through to msi2500_ctrl_msg() and again<br /> masked the original error by overwriting ret<br /> - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all,<br /> leaving isoc URBs submitted with no way for the driver to consume<br /> them<br /> <br /> Consolidate the error paths into a small goto chain. Every failure<br /> now stops the function, drains the queued-buffer list, and returns<br /> the real error code. The ctrl_msg failure path also rolls back the<br /> preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before<br /> unlocking and draining.<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").