CVE-2026-68231

What it actually does

Failure to return queued video buffers via vb2_buffer_done when airspy_start_streaming returns -ENODEV on USB disconnect causes vb2_start_streaming to trigger WARN_ON(owned_by_drv_count) and leak buffers.

Why it matters to the business

Kernel warnings and potential resource leaks in media capture pipelines on systems using Airspy USB devices can disrupt video or SDR workflows and require reboots in production environments.

How an attack unfolds

An attacker with physical access unplugs the Airspy USB device after buffers have been queued but before streaming starts, triggering the early error path that omits buffer return and produces the warning.

How to fix it

Update the Linux kernel to a version containing the fix that acquires v4l2_lock and jumps to the err_clear_bit label to drain s->queued_bufs with VB2_BUF_STATE_QUEUED before returning the error.

How to confirm the fix worked

Confirm the patched driver source contains the v4l2_lock acquisition and goto err_clear_bit before the early -ENODEV return, then test USB disconnect during buffer queuing produces no WARN_ON and all buffers are returned.

Typical attack path

1. Attach Airspy device and begin video/S DR capture setup
2. Queue buffers via buf_queue before start_streaming is called
3. Disconnect USB device to force s->udev == NULL
4. Trigger start_streaming failure path that skips buffer drain
5. Observe WARN_ON and leaked buffer state in kernel logs

How to detect it

Search kernel logs and dmesg for vb2_start_streaming WARN_ON(owned_by_drv_count) entries combined with airspy driver activity around USB disconnect events.

What your security team should do

• Apply the upstream kernel patch for the airspy driver immediately on systems using the device
• Monitor kernel logs for vb2_start_streaming WARN_ON messages on media capture hosts
• Restrict physical access to systems with attached Airspy hardware
• Test streaming start and USB removal scenarios in staging environments