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:
<pre>
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);
</pre>
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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - 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:L - 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:L - 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:N - 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:U - 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:H - 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:H - 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:H - 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.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - 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:L - 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:L - 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:N - 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:U - 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:H - 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:H - 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:H - 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.
CVSS 3.1