Description

In the Linux kernel, the following vulnerability has been resolved: media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity rockchip_vpu981_av1_dec_set_tile_info() indexes the tile group entry array by tile1 * tile_cols + tile0, reading up to tile_cols * tile_rows entries, lays out one descriptor per tile in the AV1_MAX_TILES tile_info buffer, and programs the real tile_cols / tile_rows into the hardware. The tile group entry control is a dynamic array sized to the number of entries userspace submitted, independent of tile_cols / tile_rows, so a frame that claims more tiles than entries reads past the array. A frame that claims more than AV1_MAX_TILES tiles also leaves the hardware programmed for more tiles than the descriptor buffer holds. Reject both in prepare_run(): tile_cols * tile_rows must not exceed the submitted entry count or AV1_MAX_TILES. The entry count is read via v4l2_ctrl_find() (ctrl->elems). This mirrors the bound the mediatek AV1 decoder already enforces.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-25T11:17:08.447Z",
  "pubdate": "2026-09-25T11:17:08.447Z",
  "executiveSummary": "A buffer over-read and memory corruption vulnerability exists in the Verisilicon/Rockchip AV1 video decoder implementation within the Linux kernel.\nThe vulnerability occurs due to insufficient validation of tile geometry parameters against the provided control entry array size and internal buffer constraints.\nAn unprivileged local attacker capable of submitting AV1 video frames can trigger an out-of-bounds read or potential heap memory corruption by manipulating tile configuration parameters.\nSuccessful exploitation may lead to kernel memory disclosure or system instability, typically manifesting as a kernel panic or an undefined state in the VPU hardware registers.\nThe flaw affects the media/verisilicon driver, specifically the Rockchip VPU981 decoder logic. Mitigation requires the enforcement of strict bounds checking on tile dimensions in the prepare_run() function to ensure frame tile counts do not exceed the allocated descriptor buffer or the control entry array.",
  "technicalDetails": "The vulnerability resides in the rockchip_vpu981_av1_dec_set_tile_info() function within the Linux kernel's Verisilicon media driver. The function handles the configuration of AV1 tiles for hardware decoding by calculating indices into a tile group entry array using the formula: tile1 * tile_cols + tile0.\nThe root cause is a lack of boundary validation between the hardware-programmed tile dimensions (tile_cols and tile_rows) and the actual memory allocated for tile group entries. The driver allows userspace to define a frame tile configuration that claims more tiles than the provided control entry array contains, or more than the AV1_MAX_TILES descriptor buffer limit.\nWhen processing a malicious bitstream, the driver reads past the boundaries of the user-submitted array because the hardware configuration logic assumes the entry count is implicitly large enough to accommodate the declared tile grid. Furthermore, if the tile count exceeds AV1_MAX_TILES, the driver programs the VPU hardware with values that overflow the fixed-size hardware descriptor buffer.\nExploitation flow involves an attacker crafting a malicious AV1 frame header that specifies high tile counts. Upon passing this frame to the driver, the kernel executes the index calculation, resulting in an out-of-bounds read from the kernel-space memory where the tile group entries reside. If the tile count is high enough to exceed AV1_MAX_TILES, it forces the driver to overwrite adjacent memory structures or pass invalid constraints to the hardware registers, potentially corrupting internal kernel state or the video processing unit's operation.\nThe exposure is local, requiring the ability to interact with the V4L2 (Video for Linux 2) device nodes associated with the Rockchip VPU. There are no specific privilege requirements beyond the capability to perform standard media decoding operations, making this accessible to any user in the 'video' or 'render' group. The impact is primarily a denial-of-service via kernel crash, though the memory corruption aspect could theoretically be leveraged for more complex privilege escalation depending on the memory layout of the affected kernel build."
}