CVE-2026-89881media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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/
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Sep 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | 771138920eafa399f68d3492c8a75dfeea23474b builds before 234c46b95a032232e31fa5987b84fb8f87a9693b; 771138920eafa399f68d3492c8a75dfeea23474b builds before 034b6a4f9589c04bc3f2bd5125658cd72d3e17c8; 771138920eafa399f68d3492c8a75dfeea23474b builds before 0ef9f19010ae4ba93aca211ea8f0081b9bf7aab2; 771138920eafa399f68d3492c8a75dfeea23474b builds before 053581d4657c6b5289c5de71a4828d313c005189; from 771138920eafa399f68d3492c8a75dfeea23474b before bbf15e83c37d9ac938b7c35c02b748fe54230010; 771138920eafa399f68d3492c8a75dfeea23474b builds before 7443b16b6dd8889a3b9c5236a09e7c58f0d11dae; from 771138920eafa399f68d3492c8a75dfeea23474b before a0d9d9a3b41a1346c26af57aade6ba3f552fa171; from 771138920eafa399f68d3492c8a75dfeea23474b before dabb047c62668f280998e29117c55e41aabac336 | CNA record |
References
- https://git.kernel.org/stable/c/234c46b95a032232e31fa5987b84fb8f87a9693b
- https://git.kernel.org/stable/c/034b6a4f9589c04bc3f2bd5125658cd72d3e17c8
- https://git.kernel.org/stable/c/0ef9f19010ae4ba93aca211ea8f0081b9bf7aab2
- https://git.kernel.org/stable/c/053581d4657c6b5289c5de71a4828d313c005189
- https://git.kernel.org/stable/c/bbf15e83c37d9ac938b7c35c02b748fe54230010
- https://git.kernel.org/stable/c/7443b16b6dd8889a3b9c5236a09e7c58f0d11dae
- https://git.kernel.org/stable/c/a0d9d9a3b41a1346c26af57aade6ba3f552fa171
- https://git.kernel.org/stable/c/dabb047c62668f280998e29117c55e41aabac336
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.