CVE-2026-68222

In the Linux kernel, the following vulnerability has been resolved:

media: msi2500: 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.

msi2500_start_streaming() had five error paths that all hit this trap

and were further tangled by ret-overwriting between calls:

- -ENODEV when the USB device was already disconnected

- -ERESTARTSYS when mutex_lock_interruptible() was interrupted

- msi2500_set_usb_adc() failure: ret was silently overwritten by

the next call (msi2500_isoc_init), so the error was lost entirely

- msi2500_isoc_init() failure: cleanup_queued_bufs was called, but

the function then fell through to msi2500_ctrl_msg() and again

masked the original error by overwriting ret

- msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all,

leaving isoc URBs submitted with no way for the driver to consume

them

Consolidate the error paths into a small goto chain. Every failure

now stops the function, drains the queued-buffer list, and returns

the real error code. The ctrl_msg failure path also rolls back the

preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before

unlocking and draining.

The cleanup helper takes a vb2_buffer_state argument so that the

start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as

expected by userspace on start_streaming failure) while stop_streaming

keeps its existing VB2_BUF_STATE_ERROR semantics.

This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:

Return queued buffers on start_streaming() failure").