data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-89880 in the interactive tracker

CVE-2026-89880

media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure

7.8 EPSS 0.2% AV:L

Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/media. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-89880 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormfixedDLA-4841-1 · 2026-10-17 · text6.1.190-1Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixiefixedDSA-6528-1 · 2026-09-29 · text6.12.111-1Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.2.6-1Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.2.6-1Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12fixedDLA-4817-1 · 2026-10-04 · text6.12.111-1~deb12u1Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/media/dvb-frontends/rtl2832_sdr.c

What this is
RTL2832_SDR MEDIA DRIVERMAINTAINERS section matched on drivers/media/dvb-frontends/rtl2832_sdr* · linux-media@vger.kernel.org · Orphan
Kernel module
rtl2832_sdr

Check it on the machine

grep -wE 'CONFIG_DVB_CORE|CONFIG_DVB_RTL2832_SDR' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w rtl2832_sdr

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

  • bookworm, trixie, forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
M
a module where it is built at all; some flavours do not build it
Build switches
CONFIG_DVB_CORE, CONFIG_DVB_RTL2832_SDR
Reads as
all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published
2026-09-16 (33 days ago)source
CVSS
7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector
local (AV:L)source
EPSS
0.17%, higher than 5.8% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
drivers/media

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
3.155.10.270f14a713a36a5
3.155.15.221c819dea3a433
3.156.1.1880337ab075928
3.156.6.157c91e8ae2b39c
3.156.12.1108bcf11a239ea
3.156.18.5126a2a985bbee
3.157.2.5ac02b2c56cce
3.157.3fe50cdaebf12

Debian advisories

AdvisoryDateShipped toDebian
DLA-4841-12026-10-17bookworm 6.1.190-1tracker
DLA-4817-12026-10-04bookworm 6.12.111-1~deb12u1tracker
DSA-6528-12026-09-29trixie 6.12.111-1tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local
The flaw is reached only through local V4L2 ioctls (VIDIOC_REQBUFS, VIDIOC_QBUF, VIDIOC_STREAMON) on the rtl2832_sdr /dev/swradioN node; USB bulk packets from the dongle never enter this start_streaming() error path.
AC:LAttack complexity, low
The attacker drives both STREAMON attempts and can force the first submit_urbs() failure via USBDEVFS_RESET/DISCONNECT on the matching usbfs node or GFP_KERNEL memory pressure, then retry STREAMON; no race or layout outside their control is required.
PR:LPrivileges required, low
v4l2_fh_open() and vb2_ioctl_streamon() perform no capability checks; only the SDR device node is needed, and udev uaccess/video-group rules grant it to unprivileged seat users on desktops, Android, and embedded RTL-SDR systems.
UI:NUser interaction, none
The attacking process issues REQBUFS/QBUF/STREAMON (and any usbfs reset) on its own file descriptors against an already-attached RTL2832; no separate victim action such as plugging in the dongle or opening a file is required.
S:UScope, unchanged
The urb_list[] overrun, leaked coherent DMA buffers, and resulting usb_submit_urb()/usb_free_urb() misuse stay in host kernel memory in the same OS security authority; no VM, IOMMU, or sandbox boundary is crossed.
C:HConfidentiality impact, high
After a failed STREAMON, a second alloc_urbs() leaves urbs_initialized above MAX_BULK_BUFS, so submit_urbs()/free_urbs() read past urb_list[] and treat adjacent kernel fields (including live buf_list[] DMA pointers) as struct urb objects, an out-of-bounds/type-confused kernel read.
I:HIntegrity impact, high
usb_submit_urb() writes urb->ep/status/transfer_flags through those OOB-derived pointers, and the subsequent free_urbs() walk passes the same garbage to usb_free_urb()/kref_put, a type-confusion/slab-corruption write primitive suitable for control-flow hijack.
A:HAvailability impact, high
usb_submit_urb() of the first out-of-bounds slot oopses the kernel (near-NULL from buf_num), and the attacker can repeat STREAMON after a forced submit failure to panic or hang the host at will.