CVE-2026-89894

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

media: cx231xx: reject geometry changes while the VBI queue is busy

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.