Cloudanix VulnDB

CVE-2026-68222

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in a Linux driver for certain USB devices can leak memory and trigger warnings when video streaming fails to start, potentially making affected systems less stable.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Improper error handling in msi2500_start_streaming() fails to return queued vb2 buffers via vb2_buffer_done() on any of five failure paths, triggering WARN_ON(owned_by_drv_count) and leaking buffers that may lead to memory corruption or resource exhaustion.

Why it matters to the business

Systems using the msi2500 USB SDR driver risk local instability, memory leaks, or application crashes during media streaming operations, with low but non-zero chance of escalation on affected kernels.

How an attack unfolds

A local attacker with access to the msi2500 device triggers start_streaming() error paths (USB disconnect, interrupted mutex, set_usb_adc failure, isoc_init failure, or ctrl_msg failure) to leak buffers without cleanup, resulting in kernel warnings and potential memory corruption.

How to fix it

Apply the upstream kernel patch that consolidates error paths with a goto chain, calls cleanup helpers, and returns buffers with VB2_BUF_STATE_QUEUED on start_streaming failure.

How to confirm the fix worked

Confirm the presence of the goto-based error handling and msi2500_isoc_cleanup() rollback in the driver source; inject each error path in a test environment and verify buffers are returned without WARN_ON.

Typical attack path

  1. Obtain local user access on a system with the msi2500 driver loaded
  2. Open the device and queue buffers via buf_queue()
  3. Force one of the five error conditions in start_streaming()
  4. Observe leaked buffers and kernel WARN_ON without proper vb2 return

How to detect it

Search kernel logs for WARN_ON(owned_by_drv_count) messages, msi2500_start_streaming error paths, and unexpected vb2 buffer state transitions around USB media device activity.

  • WARN_ON(owned_by_drv_count)
  • msi2500_start_streaming
  • vb2_buffer_done
  • VB2_BUF_STATE_QUEUED

What your security team should do

  • Update to a kernel containing the msi2500 start_streaming fix as soon as available
  • Monitor kernel logs for vb2 owned_by_drv_count warnings on systems exposing the device
  • Limit unprivileged access to USB video/SDR devices where feasible

The record

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").

Affected packages

Ecosystem Package Introduced Fixed