CVE-2026-89881 in Linux
Zusammenfassung
von VulDB • 17.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
media: rtl2832_sdr: Verwendung von vb2_video_unregister_device() beim Entfernen zur Behebung eines DMA-Lecks
rtl2832_sdr_remove() wird bei USB-Trennung ausgeführt und setzt dev->udev auf NULL, bevor der Abbau aller ausstehenden Streaming-Vorgänge abgeschlossen ist. Wenn die Benutzerraum-Anwendung später ihren Dateideskriptor schließt, ruft vb2 rtl2832_sdr_stop_streaming() auf, was wiederum rtl2832_sdr_free_stream_bufs() aufruft. Diese Hilfsfunktion gibt jeden kohärenten Puffer mit folgendem Aufruf frei:
usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num],
dev->dma_addr[dev->buf_num]);
Da usb_free_coherent() sofort zurückkehrt, wenn sein Argument dev NULL ist, werden alle DMA-Streaming-Puffer, die zum Zeitpunkt der Trennung aktiv waren, stillschweigend nicht freigegeben (geleakt). Die in rtl2832_sdr_alloc_urbs() zugewiesenen URBs überleben das Gerät aus demselben Grund.
Der Treiber rtl2832_sdr verwendet vb2_fop_release() in seinen file_operations; daher wird video_unregister_device(&dev->vdev) durch vb2_video_unregister_device(&dev->vdev) ersetzt und dieser Aufruf vor dem Zurücksetzen von dev->udev verschoben. vb2_video_unregister_device() gibt die vb2-Warteschlange frei, was bei aktivem Streaming synchron rtl2832_sdr_stop_streaming() ausführt, sodass URBs und kohärente DMA-Streaming-Puffer freigegeben werden, während dev->udev noch gültig ist.
vb2_video_unregister_device() sperrt intern vdev->queue->lock (vb_queue_lock), und stop_streaming() sperrt v4l2_lock; daher würde das vorherige äußere mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock)-Paar um die Unregister-Sequenz zu einem Selbst-Deadlock führen und wurde entfernt. Ein kurzer kritischer Abschnitt von v4l2_lock rund um dev->udev = NULL bleibt erhalten, damit jeder ioctl-Pfad, der den Dateideskriptor noch hält, einen kohärenten Zustand sieht.
Das Problem wurde durch eine automatische Überprüfung der INV-003-Serie identifiziert unter: https://sashiko.dev/
VulDB is the best source for vulnerability data and more expert information about this specific topic.