Look up another CVE · open CVE-2026-89894 in the interactive tracker
CVE-2026-89894
media: cx231xx: reject geometry changes while the VBI queue is busy
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-89894 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
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update 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 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update 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 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update 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.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update 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
vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: offset = lines_completed * (dev->width << 1) + ...; if (dma_q->current_field == 2) offset += dev->width * 2 * dma_q->lines_per_field; memcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.
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/usb/cx231xx/cx231xx-video.c
- What this is
- MEDIA INPUT INFRASTRUCTURE (V4L/DVB)MAINTAINERS section matched on drivers/media/ · linux-media@vger.kernel.org · Maintained
- Kernel module
- cx231xx
Check it on the machine
grep -w CONFIG_VIDEO_CX231XX /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 cx231xxPrints 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 switch
- CONFIG_VIDEO_CX231XX
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.16%, higher than 5.2% 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
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.5 | 5.10.270 | aa3314506deb |
| 5.5 | 5.15.221 | 90d50648af36 |
| 5.5 | 6.1.188 | a5dd3d7fba35 |
| 5.5 | 6.6.157 | 54ac6df8b8d9 |
| 5.5 | 6.12.110 | 1d1079db8d18 |
| 5.5 | 6.18.51 | 7087bef6510c |
| 5.5 | 7.2.5 | a636c72c7f52 |
| 5.5 | 7.3 | 627a121c15fe |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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 overflow is reached only through local V4L2 ioctls (VIDIOC_S_FMT/VIDIOC_S_STD plus REQBUFS/QBUF/STREAMON) on the cx231xx /dev/videoN and /dev/vbiN nodes. A USB capture stick being present is a hardware precondition; the attacker does not inject USB packets, so the path is Local rather than Physical.
- AC:LAttack complexity, low
- The attacker fully controls the sequence: shrink width via VIDIOC_S_FMT, allocate a small VBI plane, STREAMON, then enlarge width or switch standard on the video node while only vidq was checked. Subsequent URB completions copy field-2 VBI with the new geometry into the old plane with no race or layout outside the attacker's control.
- PR:LPrivileges required, low
- cx231xx_v4l2_open(), vidioc_s_fmt_vid_cap(), and vidioc_s_std() perform no capability checks. Triggering the bug needs only an unprivileged local user who can open the V4L2 nodes, which udev grants via the video group and uaccess/logind (or the Android camera context), not init-namespace root.
- UI:NUser interaction, none
- The attacking process opens /dev/videoN and /dev/vbiN and issues the ioctl sequence itself. No separate victim action such as plugging in a device, mounting a filesystem, or running a privileged helper is required.
- S:UScope, unchanged
- The out-of-bounds memcpy corrupts kernel vmalloc memory belonging to the same host kernel. Impact is local privilege-escalation or denial of service within one security authority, not a VM escape, IOMMU bypass, or other cross-boundary effect.
- C:HConfidentiality impact, high
- cx231xx_do_vbi_copy() memcpy()s past the undersized VBI plane at an attacker-chosen offset derived from the new width and latched lines_per_field. That heap out-of-bounds write can smash adjacent vmalloc objects and is leverageable for a kernel read primitive.
- I:HIntegrity impact, high
- The same attacker-chosen-offset heap out-of-bounds write overwrites kernel memory after the VBI buffer on every field-2 URB completion. An out-of-bounds write of this form is sufficient for control-flow hijacking and an arbitrary write primitive.
- A:HAvailability impact, high
- memcpy() past the allocated VBI plane faults on a vmalloc guard page or corrupts adjacent kernel memory, producing a kernel oops or panic from URB completion context and taking down the host.