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

Published Sep 16, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

media: rtl2832sdr: use vb2videounregisterdevice() on remove to fix DMA leak

rtl2832sdrremove() 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 rtl2832sdrstopstreaming() which in turn calls rtl2832sdrfreestreambufs(). That helper releases each coherent buffer with:

usbfreecoherent(dev->udev, dev->bufsize, dev->buflist[dev->bufnum], dev->dmaaddr[dev->bufnum]);

usbfreecoherent() 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 rtl2832sdrallocurbs() outlive the device for the same reason.

The rtl2832sdr driver uses vb2foprelease() in its fileoperations, so replace videounregisterdevice(&dev->vdev) with vb2videounregisterdevice(&dev->vdev) and move it before clearing dev->udev. vb2videounregisterdevice() releases the vb2 queue, which synchronously runs rtl2832sdrstopstreaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid.

vb2videounregisterdevice() locks vdev->queue->lock (vbqueuelock) internally, and stopstreaming() locks v4l2lock, so the previous outer mutexlock(&dev->vbqueuelock) / mutexlock(&dev->v4l2lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2lock 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 Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Linux kernel media: rtl2832_sdr to a version that resolves this vulnerability.

    Patch INV-003
  2. Configuration

    In rtl2832_sdr_remove(), replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev); ensure usb_free_coherent(dev->udev, dev->buf_size, ...) is performed before clearing dev->udev so coherent DMA buffers/URBs are freed while dev->udev is still valid.

    rtl2832_sdr driver (Linux kernel) remove path: replace vb2 unregistration order = Use vb2_video_unregister_device(&dev->vdev) and move usb_free_coherent(...) before clearing dev->udev

Event History

Sep 16, 2026
CVE Published
via MITRE·10:31 AM
Data Sourced
via MITRE·10:31 AM
Description

Frequently Asked Questions

1

When does the leak occur?

It occurs when an rtl2832_sdr USB device disconnects while DMA streaming resources are still live. The affected path is triggered when streaming teardown is deferred until user space closes its file descriptor after the disconnect.

2

What conditions are required to trigger it?

An rtl2832_sdr device must be in use with allocated streaming buffers or URBs, then disconnect before pending streaming teardown completes. The file descriptor can remain open at disconnect and be closed later, causing cleanup to run after the USB device pointer has been cleared.

3

How can I tell whether a system may have encountered the issue?

Systems are relevant if they use the rtl2832_sdr driver and a USB disconnect occurred during active SDR streaming or before the application closed its device file descriptor. In that scenario, coherent DMA stream buffers and URBs allocated for the stream may remain leaked.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203