Cloudanix VulnDB

CVE-2026-68213

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A driver bug could cause memory accounting warnings and leaked buffers on certain radio hardware when streaming fails to start, but the problem is not being exploited and is fixed by a normal kernel update.

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

What it actually does

Failure to return vb2 buffers via vb2_buffer_done() on any of eight error paths in rtl2832_sdr_start_streaming() triggers WARN_ON(owned_by_drv_count) and leaks the buffers, constituting a kernel memory accounting corruption.

Why it matters to the business

Linux systems using RTL2832-based SDR hardware may experience driver warnings, streaming failures, or gradual memory pressure after repeated start attempts; the issue is not known to be exploited and carries low urgency.

How an attack unfolds

An attacker with local access or the ability to trigger repeated start_streaming calls on the rtl2832_sdr device could force the error paths, leaking buffers and producing kernel warnings; no remote or unauthenticated exploitation path exists and no threat actors have been observed using it.

How to fix it

Update the Linux kernel to a version containing the referenced fix that adds rtl2832_sdr_cleanup_queued_bufs() and an explicit success return path; no configuration changes or workarounds are required.

How to confirm the fix worked

Confirm the patch is present by inspecting the rtl2832_sdr driver source for the cleanup helper call at the err label and before early returns; test by inducing start_streaming failures and verifying no WARN_ON occurs and buffers are returned with VB2_BUF_STATE_QUEUED.

Typical attack path

  1. Obtain local access or control of a process that can open the SDR device
  2. Repeatedly issue VIDIOC_STREAMON or equivalent ioctls that reach start_streaming()
  3. Force one of the documented error conditions (ENODEV, ERESTARTSYS, subdev/tuner/ADC/URB failures)
  4. Observe leaked buffers and kernel WARN_ON in logs

How to detect it

Search kernel logs for the specific WARN_ON string referencing owned_by_drv_count together with rtl2832_sdr; inspect crash dumps or memory-leak reports on hosts exposing the RTL2832 SDR device.

What your security team should do

  • Apply the kernel update containing the fix at the next scheduled patch cycle
  • Monitor dmesg for "owned_by_drv_count" warnings on systems using rtl2832_sdr
  • No immediate action required given low EPSS and absence from KEV

The record

In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: 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. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and "return ret". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. 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"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.

Affected packages

Ecosystem Package Introduced Fixed