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 bufqueue() before calling startstreaming(). If startstreaming() returns an error without first returning those buffers via vb2bufferdone(), vb2startstreaming() fires WARNON(ownedbydrv_count) and the queued buffers leak.

msi2500startstreaming() 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 mutexlockinterruptible() was interrupted
• msi2500setusbadc() failure: ret was silently overwritten by the next call (msi2500isoc_init), so the error was lost entirely
• msi2500isocinit() failure: cleanupqueuedbufs was called, but the function then fell through to msi2500ctrlmsg() and again masked the original error by overwriting ret
• msi2500ctrlmsg(CMDSTARTSTREAMING) 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 ctrlmsg failure path also rolls back the preceding msi2500isocinit() via msi2500isoc_cleanup() before unlocking and draining.

The cleanup helper takes a vb2bufferstate argument so that the startstreaming error paths can pass VB2BUFSTATEQUEUED (as expected by userspace on startstreaming failure) while stopstreaming keeps its existing VB2BUFSTATE_ERROR semantics.

This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure").