CVE-2026-89881
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/
Executive briefing
A structured intelligence assessment has not yet been generated. The source description is shown above. The background enrichment worker will retry this record.
Evidence confidence: Not assessed Evidence-derived, not an exploitability verdict
Severity & attack characteristics
CVSS vector:Not supplied
No CVSS vector is currently available in the source record.
Technical explanation & impact
Technical root-cause details are not available in the current source record.
Assess the impact using the published CVSS metrics and the affected vendor component.
Affected products and versions
NVD has not supplied machine-readable vulnerable CPE product/version entries for this CVE. This is an information gap, not proof that no products are affected. Check the vendor advisory references below.
Remediation & validation
- Identify exposure by comparing the affected product and version ranges with your asset inventory, SBOM and externally exposed services.
- Review the linked vendor security advisory or patch notes. Upgrade to a vendor-confirmed fixed release; do not infer a fixed version from the CVE description.
- Until patched, consider restricting network access or disabling the affected feature where operationally safe. These are temporary controls, not a substitute for a vendor fix.
- Validate the remediation with a version check and vulnerability rescan, then retain change evidence.
No fixed version is displayed unless it is explicitly established by a vendor advisory. Follow the vendor's release notes for exact product and branch applicability.
Vendor advisories, patches & exploit references
No external references are currently supplied in the CVE record.