GHSA-64C5-3GXH-7523
Vulnerability from github – Published: 2026-09-16 12:30 – Updated: 2026-09-16 12:30In 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/
{
"affected": [],
"aliases": [
"CVE-2026-89881"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-16T11:16:56Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak\n\nrtl2832_sdr_remove() runs on USB disconnect and clears dev-\u003eudev to\nNULL before any pending streaming teardown has run. When user space\nlater closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming()\nwhich in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases\neach coherent buffer with:\n\n usb_free_coherent(dev-\u003eudev, dev-\u003ebuf_size,\n dev-\u003ebuf_list[dev-\u003ebuf_num],\n dev-\u003edma_addr[dev-\u003ebuf_num]);\n\nusb_free_coherent() returns immediately when its dev argument is NULL,\nso every DMA stream buffer that was live at disconnect is silently\nleaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the\ndevice for the same reason.\n\nThe rtl2832_sdr driver uses vb2_fop_release() in its file_operations,\nso replace video_unregister_device(\u0026dev-\u003evdev) with\nvb2_video_unregister_device(\u0026dev-\u003evdev) and move it before clearing\ndev-\u003eudev. vb2_video_unregister_device() releases the vb2 queue, which\nsynchronously runs rtl2832_sdr_stop_streaming() if streaming is active,\nso URBs and coherent DMA stream buffers are freed while dev-\u003eudev is\nstill valid.\n\nvb2_video_unregister_device() locks vdev-\u003equeue-\u003elock (vb_queue_lock)\ninternally, and stop_streaming() locks v4l2_lock, so the previous outer\nmutex_lock(\u0026dev-\u003evb_queue_lock) / mutex_lock(\u0026dev-\u003ev4l2_lock) pair\naround the unregister sequence would self-deadlock and has been removed.\nA short v4l2_lock critical section around dev-\u003eudev = NULL remains so\nany ioctl path that still holds the file descriptor sees coherent state.\n\nIssue identified by automated review of the INV-003 series at\nhttps://sashiko.dev/",
"id": "GHSA-64c5-3gxh-7523",
"modified": "2026-09-16T12:30:40Z",
"published": "2026-09-16T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89881"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/034b6a4f9589c04bc3f2bd5125658cd72d3e17c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/053581d4657c6b5289c5de71a4828d313c005189"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ef9f19010ae4ba93aca211ea8f0081b9bf7aab2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/234c46b95a032232e31fa5987b84fb8f87a9693b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7443b16b6dd8889a3b9c5236a09e7c58f0d11dae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0d9d9a3b41a1346c26af57aade6ba3f552fa171"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbf15e83c37d9ac938b7c35c02b748fe54230010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dabb047c62668f280998e29117c55e41aabac336"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.