In the Linux kernel, the following vulnerability has been resolved:
media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer
rockchip_vpu981_av1_dec_set_tile_info() divides context_update_tile_id by
tile_info->tile_cols and writes one descriptor per tile into the tile_info
DMA buffer, which holds AV1_MAX_TILES entries; tile_cols and tile_rows
come from the bitstream. Guard the division against a zero tile_cols by
initialising the context-update values to zero and computing them only
when tile_cols is non-zero, and stop the descriptor writes once the
tile_info buffer is full. The tile geometry written to the hardware
registers is left unmodified; the per-dimension and total tile bounds are
enforced by the control validation.
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 bad tile_cols/tile_rows reach rockchip_vpu981_av1_dec_set_tile_info() through the V4L2_CID_STATELESS_AV1_FRAME control, set with VIDIOC_S_EXT_CTRLS/media request ioctls on the local hantro /dev/videoN node and run via rockchip_vpu981_av1_dec_run(). No remote protocol carries the values; a userspace AV1 parser would have to pass through values that break the spec.
AC:L - validate_av1_frame() never checks tile_cols or tile_rows, so any caller can set tile_cols=0 (divide by zero) or 255x255 tiles (writes far past the 2 KiB tile_info buffer). Nothing outside the attacker's control is needed; the fault happens every time the job runs.
PR:L - The only requirement is opening the VPU981 AV1 stateless decoder video node, which the logged-in user (video group) or the Android/ChromeOS media codec process normally can do. The ioctl path has no capability check.
UI:N - The attacker queues the malicious control and request themselves, and the device_run worker processes it without any action by another user.
S:U - The corruption stays in the kernel's own memory and security authority. No VM, IOMMU, or other boundary is crossed.
C:H - tile_id reaches about 65,000 while the tile_group_entry dynamic array holds at most 512 entries, and indexes of width/height_in_sbs_minus_1 above 64 run past those arrays. Out-of-bounds kernel data is read into the descriptors, and the memory corruption can be used to leak data.
I:H - The loop writes 16 bytes per tile, up to 255*255 tiles (about 1 MiB), past the 128-entry (2 KiB) dma_alloc_coherent tile_info buffer. The x0/y0/start/end values it writes are largely user-controlled, so it is a large, content-controlled kernel memory overwrite.
A:H - tile_cols=0 causes a divide error when computing context_update_tile_id, which oopses the kernel. The large out-of-bounds write also corrupts memory next to the buffer and crashes the system.
| 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 bad tile_cols/tile_rows reach rockchip_vpu981_av1_dec_set_tile_info() through the V4L2_CID_STATELESS_AV1_FRAME control, set with VIDIOC_S_EXT_CTRLS/media request ioctls on the local hantro /dev/videoN node and run via rockchip_vpu981_av1_dec_run(). No remote protocol carries the values; a userspace AV1 parser would have to pass through values that break the spec.
AC:L - validate_av1_frame() never checks tile_cols or tile_rows, so any caller can set tile_cols=0 (divide by zero) or 255x255 tiles (writes far past the 2 KiB tile_info buffer). Nothing outside the attacker's control is needed; the fault happens every time the job runs.
PR:L - The only requirement is opening the VPU981 AV1 stateless decoder video node, which the logged-in user (video group) or the Android/ChromeOS media codec process normally can do. The ioctl path has no capability check.
UI:N - The attacker queues the malicious control and request themselves, and the device_run worker processes it without any action by another user.
S:U - The corruption stays in the kernel's own memory and security authority. No VM, IOMMU, or other boundary is crossed.
C:H - tile_id reaches about 65,000 while the tile_group_entry dynamic array holds at most 512 entries, and indexes of width/height_in_sbs_minus_1 above 64 run past those arrays. Out-of-bounds kernel data is read into the descriptors, and the memory corruption can be used to leak data.
I:H - The loop writes 16 bytes per tile, up to 255*255 tiles (about 1 MiB), past the 128-entry (2 KiB) dma_alloc_coherent tile_info buffer. The x0/y0/start/end values it writes are largely user-controlled, so it is a large, content-controlled kernel memory overwrite.
A:H - tile_cols=0 causes a divide error when computing context_update_tile_id, which oopses the kernel. The large out-of-bounds write also corrupts memory next to the buffer and crashes the system.
CVSS 3.1