DF-3698 — cu_info bitmap[4][4] indexed by unclamped max_shader_engines / max_sh_per_se from firmware → heap OOB write

Where

• OOB write/read sites: sys/dev/drm/amd/amdgpu/gfx_v9_0.c:4990-5013 (gfx_v9_0_get_cu_info: cu_info->bitmap[i][j], cu_info->ao_cu_bitmap[i][j]) and gfx_v9_0.c:937-958 (gfx_v9_0_init_always_on_cu_mask, same arrays, read at :945, write at :958).
• Array dimensions: sys/dev/drm/amd/amdgpu/amdgpu_gfx.h:197-198 — uint32_t ao_cu_bitmap[4][4]; uint32_t bitmap[4][4]; (inside struct amdgpu_cu_info, embedded as adev->gfx.cu_info in the heap amdgpu_device object).
• Unclamped bounds source #1 (fw file): amdgpu_device.c:1379-1381 — max_shader_engines = le32_to_cpu(gpu_info_fw->gc_num_se) from amdgpufw_<asic>_gpu_info (loaded for vega10/vega12/raven/picasso/raven2, amdgpu_device.c:61-65; amdgpu_ucode_validate here only checks size_bytes == datasize).
• Unclamped bounds source #2 (VBIOS): gfx_v9_0.c:1422 → amdgpu_atomfirmware.c:349 (gc_num_se u8 ≤ 255 from the atom gfx_info table, VEGA20 path).

Reproduce

build.sh   # cc -O2 -o fwgen_gi fwgen_craft_gpuinfo.c  (ran on DF 6.5 guest, cc 8.3)
run.sh     # ./fwgen_gi -> amdgpufw_raven_gpu_info.evil (96 bytes, gc_num_se=64)

On hardware: install the blob as the gpu_info firmware file and load the driver — gc_num_se=64 makes gfx_v9_0_get_cu_info (called from gfx_v9_0_constants_init, gfx_v9_0.c:1971, at hw_init) iterate i = 0..63, writing bitmap[i][j] up to 960 bytes past the end of the 64-byte [4][4] array — a linear heap overwrite of everything after adev->gfx.cu_info inside amdgpu_device, with GPU-register-derived u32 values. On Raven, gfx_v9_0_init_always_on_cu_mask (sw_init → gfx_v9_0_rlc_init → init_lbpw) hits the same overflow even earlier. This guest has no AMD GPU (virtio-vga only), so the path cannot run here.

Expected (on hardware)

Kernel heap corruption immediately after adev->gfx.cu_info (mutex pointers, function-pointer-adjacent fields, then adjacent heap objects) → near-certain panic, plausibly exploitable with control of the following heap layout.

Threat model

Attacker controls the gpu_info firmware file (root path replacement / compromised distribution) or the GPU VBIOS. Same threat class as pass-1 findings DF-1176/1177/1178 (firmware-parsing, filed Medium).

Fix

fix.diff — bound the loops to the array dimensions in both functions and clamp the config after the VBIOS read in gfx_v9_0_gpu_early_init.

DF-3698 — VERDICT

status: not_reproduced (hardware absent) · source-level: certain

The chain, line by line (this tree)

1. amdgpu_device_ip_early_init (amdgpu_device.c:1490) unconditionally runs amdgpu_device_parse_gpu_info_fw for soc15 asics.
2. amdgpu_device_parse_gpu_info_fw (amdgpu_device.c:1301-1395) requests amdgpufw_<asic>_gpu_info (vega10/vega12/raven/picasso/raven2 — amdgpu_device.c:61-65), "validates" it with amdgpu_ucode_validate which in this tree is only fw->datasize == hdr->size_bytes (amdgpu_ucode.c:251-259), then assigns max_shader_engines = le32(gpu_info_fw->gc_num_se) (:1379) and max_sh_per_se = le32(...gc_num_sh_per_se) (:1381) — raw u32s, no clamp. VEGA20 has a second source: gfx_v9_0.c:1422 → amdgpu_atomfirmware_get_gfx_info (amdgpu_atomfirmware.c:349-351, u8 fields from VBIOS, ≤255, still ≫ 4).
3. gfx_v9_0_get_cu_info (gfx_v9_0.c:4977-5024) loops i < max_shader_engines, j < max_sh_per_se and writes cu_info->bitmap[i][j] = bitmap; (:5000) and cu_info->ao_cu_bitmap[i][j] = ao_bitmap; (:5013). The arrays are fixed [4][4] (amdgpu_gfx.h:197-198). With gc_num_se = 64 the write index runs to bitmap[63][3] — 960 bytes past a 64-byte array, inside the heap amdgpu_device. Written values are GPU register reads (CU active bitmaps, small u32s) — not fully attacker-chosen, but structurally a linear kernel heap overwrite. It also OOB-reads cu_info->bitmap[i][j] at :945 via gfx_v9_0_init_always_on_cu_mask (:937-958, write at :958), reached from sw_init on Raven (gfx_v9_0_rlc_init → gfx_v9_0_init_lbpw) — i.e. before gfx_v9_0_gpu_early_init would ever run, so a clamp placed only there is insufficient (the fix bounds the loops themselves).
4. Reachability: get_cu_info runs at gfx_v9_0_hw_init → gfx_v9_0_constants_init (gfx_v9_0.c:1971) and again from the AMDGPU_INFO_CUINFO ioctl path (amdgpu_gfx...get_cu_info func table gfx_v9_0.c:1378-1385); init_always_on_cu_mask at sw_init (Raven).

Distinct from DF-1176/1177/1178 (those are RLC/MEC firmware header parsing; this is the gpu_info/VBIOS-derived config feeding fixed-size array loops).

Verification run (guest, virtio-only)

• Guest: DragonFly 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026, x86_64.
• amdgpu.ko present in /boot/kernel, kldload amdgpu OK — the vulnerable code ships in the guest kernel build.
• pciconf -lv → zero vendor-0x1002 devices; only virtio-vga (chip=0x11111234). amdgpu_pci_probe never matches → the driver never reaches sw_init/parse_gpu_info_fw → runtime-unreachable on this guest; honest not_reproduced, not a refutation: every source link is cited and was re-verified in this tree.
• Trigger generator builds and runs on the guest (cc 8.3), emitting amdgpufw_raven_gpu_info.evil (96 bytes; header v1.0, gc_num_se=64, gc_num_sh_per_se=4, size_bytes=96=datasize so the tree's validator passes it). Logs: build.log, run.log, env.txt.

Impact ceiling (on hardware)

Heap OOB write with partially controlled length (gc_num_se/gc_num_sh_per_se u32, effectively unbounded iteration → runs until fault) and semi-controlled data (GPU-register-derived u32 bitmaps) over the tail of amdgpu_device → kernel panic at minimum; plausible corruption of mutexes/pointers following adev->gfx.cu_info, i.e. potential privilege escalation given firmware-file control (which already implies root file access, so practically: defense against malicious/corrupt firmware + supply chain).

Fix validation

fix.diff bounds both loops (min(x,4)) and clamps config after the VEGA20 VBIOS read. Not runtime-testable here (no AMD hardware): fix_status: not_tested, baseline not reproduced for the same reason.

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.