0.0
NA
CVE-2026-89881
media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak
Description

In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/

INFO

Published Date :

Sept. 16, 2026, 11:16 a.m.

Last Modified :

Sept. 16, 2026, 11:16 a.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2026-89881 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel
Solution
Fix DMA leak by updating device unregistration and buffer freeing logic.
  • Replace video_unregister_device with vb2_video_unregister_device.
  • Move device unregistration before clearing device udev.
  • Remove self-deadlocking mutex locks.
  • Retain v4l2_lock for coherent state.
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-89881 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-89881 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2026-89881 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2026-89881 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Sep. 16, 2026

    Action Type Old Value New Value
    Added Description In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/
    Added Affected New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/89xxx/CVE-2026-89881.json">CVE-2026-89881</a>
    Added Reference https://git.kernel.org/stable/c/034b6a4f9589c04bc3f2bd5125658cd72d3e17c8
    Added Reference https://git.kernel.org/stable/c/053581d4657c6b5289c5de71a4828d313c005189
    Added Reference https://git.kernel.org/stable/c/0ef9f19010ae4ba93aca211ea8f0081b9bf7aab2
    Added Reference https://git.kernel.org/stable/c/234c46b95a032232e31fa5987b84fb8f87a9693b
    Added Reference https://git.kernel.org/stable/c/7443b16b6dd8889a3b9c5236a09e7c58f0d11dae
    Added Reference https://git.kernel.org/stable/c/a0d9d9a3b41a1346c26af57aade6ba3f552fa171
    Added Reference https://git.kernel.org/stable/c/bbf15e83c37d9ac938b7c35c02b748fe54230010
    Added Reference https://git.kernel.org/stable/c/dabb047c62668f280998e29117c55e41aabac336
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.