CVE-2026-68206

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 control is only settable through VIDIOC_S_EXT_CTRLS on the local V4L2 stateless decoder node (/dev/videoN), followed by QBUF/STREAMON on the same fd. There is no network or remote path into the HEVC slice-params control.

AC:LAttack complexity, low

The attacker supplies num_ref_idx_l0/l1_active_minus1 verbatim as a u8; any value in 16..254 deterministically drives the loops in cedrus_h265_is_low_delay() and rkvdec_hevc set_ps_field() out of bounds on the very next decode run. No race, timing window, or uncontrollable memory layout is involved.

PR:LPrivileges required, low

Only an unprivileged local account holding the video device node is required (typically the 'video' group, or the media/codec service reachable from sandboxed apps on Android and embedded Allwinner/Rockchip devices). cedrus_try_ctrl() checks only SPS chroma format and bit depth; no capability or root check exists on the path.

UI:NUser interaction, none

The attacking process performs the whole sequence itself: open the decoder, set the crafted HEVC slice-params control, queue buffers and start streaming. No victim action, media file, or mount is needed.

S:UScope, unchanged

The out-of-bounds accesses stay inside the kernel's own slab and DMA memory within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

decode_params->dpb[] holds 16 16-byte entries at the tail of a ~336-byte control allocation, so an index up to 255 reads roughly 3.8 KB of adjacent kernel heap; the pred-weight loops likewise read 240 bytes past slice_params. Those OOB bytes are fed into decoder SRAM and steer the low-delay decision, giving an attacker-steerable oracle over unrelated kernel memory.

I:HIntegrity impact, high

In rkvdec-hevc, REF_PIC_IDX_L0(i)/REF_PIC_LONG_TERM_L1(i) with i up to 255 resolve to bit offset ~1276 in an 8-word rkvdec_rps_packet, so set_ps_field() performs an out-of-bounds write of attacker-chosen bits at an attacker-chosen offset into (and past the end of) the coherent DMA priv_tbl, corrupting hardware descriptor state and adjacent memory.

A:HAvailability impact, high

Reading several kilobytes past a slab object can walk into an unmapped or poisoned region and trips KASAN/hardening checks, while the rkvdec out-of-bounds write corrupts the DMA table handed to the decoder; either yields a kernel oops or wedged hardware, repeatable at will from an unprivileged process.