CVE-2026-68222
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk4th percentile - higher than 4% of all known CVEs
Summary
In the Linux kernel, a vulnerability in the msi2500 driver (MSI2500 SDR receiver) causes queued vb2 buffers to leak when start_streaming() fails. Five error paths failed to return buffers to the vb2 framework, triggering WARN_ON and memory leaks. The fix consolidates error handling, ensuring all buffers are returned and the correct error code is propagated.
Risk Assessment
The risk includes kernel memory leaks and potential system instability when using SDR devices, especially during USB disconnects or interrupts. This could lead to performance degradation or system crashes in environments heavily using media capture.
Recommendation
Apply the patch from the official Linux kernel repository that fixes CVE-2026-68222 immediately. Update the kernel to a version containing this commit or apply a backport.
Original NVD description (English source)
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").