CVE-2026-89881
media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak
Published Sep 16, 2026
CVSS n/a
EPSS < 1%
KEV · Not listed
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/
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/
Affected Products
-
CVE record
-
NVD configurations
No data
-
Red Hat packages
No data
-
OpenCVE enrichment
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
|||||||||||||||||||||||||||||||||
| Linux | Linux | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Kernel |
|
||||||||||||||||||||||||||||||||||||||||||||
| Linux | Kernel |
|
Remediation
Tracking
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4817-1 | linux-6.12 security update |
| Debian DLA |
DLA-4841-1 | linux security update |
 Debian DSA |
DSA-6528-1 | linux security update |
 Ubuntu USN |
USN-8961-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9019-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9020-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9022-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9023-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9024-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9025-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9026-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9029-1 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-9039-1 | Linux kernel (Azure CVM) vulnerabilities |
| Ubuntu USN |
USN-9040-1 | Linux kernel (Low Latency NVIDIA) vulnerabilities |
| Ubuntu USN |
USN-9066-1 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-9091-1 | Linux kernel (NVIDIA Tegra) vulnerabilities |
Metrics
No CVSS v4.0
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.216% probability within 30 days)
Key SSVC decision points have not yet been added.
References
History
Sep 19, 2026 11:45 AM
First appearance in the feed. Affected vendors updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux kernel
|
|
| Vendors & Products |
Linux kernel
|
Sep 18, 2026 8:45 AM
Weaknesses updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-789 |
Sep 16, 2026 10:45 AM
Description updated. Title updated. First appearance in the feed. Affected versions updated. Affected vendors updated. Added references
View changes
| Type | Values Removed | Values 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/ | |
| Title | media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
|
Weaknesses
