DF-4608 — radeon_vce_cs_reloc() NULL-deref panic: CS submitted without a relocation chunk

File: sys/dev/drm/radeon/radeon_vce.c (pass 2) Severity: Medium (deterministic local kernel panic from unprivileged DRM access) Confidence: certain CWE: CWE-476

The path

A DRM_IOCTL_RADEON_CS submission is parsed by radeon_cs_parser_init() (radeon_cs.c:302-361): it sets p->chunk_relocs only if the user supplied a RADEON_CHUNK_ID_RELOCS chunk (radeon_cs.c:313-315) — omitting the chunk is perfectly legal. radeon_cs_parser_relocs() (radeon_cs.c:83-85) then returns 0 ("nothing to do") instead of rejecting, and p->relocs/p->chunk_relocs stay NULL (the parser was memset in radeon_cs_ioctl, radeon_cs.c:674).

Selecting a VCE ring (FLAGS chunk dword 1 = RADEON_CS_RING_VCE, no RADEON_CS_USE_VM) dispatches radeon_vce_cs_parse (radeon_asic.c:1769/2077). Its very first reloc-bearing command — e.g. 0x05000005 feedback buffer (radeon_vce.c:646-651) — calls radeon_vce_cs_reloc():

relocs_chunk = p->chunk_relocs;                       /* NULL */
offset = radeon_get_ib_value(p, lo);
idx = radeon_get_ib_value(p, hi);
if (idx >= relocs_chunk->length_dw) {                  /* NULL deref */

→ kernel page fault at offsetof(struct radeon_cs_chunk, length_dw) → panic. Any local user with the DRM node open (typically unprivileged /dev/dri/renderD128 on desktops) can panic the machine, deterministically, with a single ioctl.

The guards everyone else has (and VCE forgot)

• generic packet path radeon_cs_packet_next_reloc() — radeon_cs.c:846-850: if (p->chunk_relocs == NULL) { DRM_ERROR("No relocation chunk !"); return -EINVAL; }
• UVD parser radeon_uvd_cs_parse() — radeon_uvd.c:705-709: the identical guard, at the head of the parser.

radeon_vce_cs_parse()/radeon_vce_cs_reloc() have no such check anywhere — a plain oversight when VCE support was ported.

Trigger

vce_null_relocs.c: raw ioctl (no libdrm), FLAGS chunk selecting the VCE ring + IB chunk containing a session command followed by a feedback-buffer command, and deliberately no RELOCS chunk.

Guest status

Builds clean with the guest cc 8.3. The audit QEMU guest has no radeon GPU (ls /dev/dri → absent; pciconf -l | grep 1002 → zero matches), so the ioctl cannot be exercised — trigger provided for affected hardware (TAHITI/PITCAIRN/VERDE/OLAND/ARUBA/BONAIRE/KAVERI/KABINI/HAWAII/MULLINS with radeonkms loaded and the VCE rings up).

Fix

Mirror the UVD guard at the head of radeon_vce_cs_parse() (fix.diff).

DF-4608 VERDICT

Status: untested (hardware-required) — code-trace certainty

Proof chain (all path:line)

1. radeon_cs_ioctl memsets the parser (radeon_cs.c:674) → chunk_relocs NULL by default.
2. radeon_cs_parser_init assigns p->chunk_relocs only for a RADEON_CHUNK_ID_RELOCS chunk (radeon_cs.c:313-315). A CS consisting of FLAGS+IB chunks only is fully accepted (IB length != 0 checked at :319; ring validity at :371 via radeon_cs_get_ring; VCE cs_parse non-NULL checked at :376).
3. radeon_cs_parser_relocs early-returns 0 when chunk_relocs == NULL (radeon_cs.c:83-85) — the submission is NOT rejected.
4. radeon_cs_ib_chunk → radeon_cs_parse(rdev, ring, parser) (radeon_cs.c:466) → (rdev)->asic->ring[r]->cs_parse(p) (radeon.h:2726) → radeon_vce_cs_parse for TN_RING_TYPE_VCE1/2 (radeon_asic.c:1769, 2077).
5. radeon_vce_cs_parse case 0x05000005 (radeon_vce.c:646-651) (or encode 0x03000001 :615, context 0x05000001 :631, bitstream 0x05000004 :638) → radeon_vce_cs_reloc → relocs_chunk = p->chunk_relocs (radeon_vce.c:478) → if (idx >= relocs_chunk->length_dw) (radeon_vce.c:482) dereferences NULL + offsetof(length_dw)=4 → unrecoverable kernel page fault → panic.
6. Comparative guards that prove intent: radeon_cs.c:846-850 (generic reloc path) and radeon_uvd.c:705-709 (UVD parser) both reject a missing relocs chunk with "No relocation chunk !". The VCE parser has no equivalent.

The trigger (vce_null_relocs.c) compiles clean on the guest (build.log) and performs the ioctl; on this guest it exits at the /dev/dri open (run.log: "No such file or directory ... this guest has no radeon GPU"); pciconf lists zero 1002: devices. Execution requires radeon hardware with the VCE block (SI/CIK asics) — not present in the QEMU guest, matching the audit precedent for GPU findings (cf. DF-4447). Deterministic panic when run on affected hardware; no memory-corruption primitive (NULL fixed offset read on x86-64 with the NULL page unmapped → page fault → panic).

Fix

fix.diff adds the same guard radeon_uvd_cs_parse has, at the head of radeon_vce_cs_parse. fix_status=not_testable (no radeon GPU on the audit guest).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.