amdgpu_vcn: firmware header fields used without bounds checks - heap overflow via crafted firmware (defense-in-depth)
Summary
amdgpu_vcn_sw_init at 124-126: bo_size = STACK+CONTEXT; if load_type!=PSP bo_size += PAGE_ALIGN(le32_to_cpu(hdr->ucode_size_bytes) + 8) - the +8 is u32 arithmetic can wrap if ucode_size_bytes=0xFFFFFFF8 -> 0, BO sized only ~640KB+PAGE_SIZE. amdgpu_vcn_resume at 203-209: offset=ucode_array_offset_bytes; memcpy_toio(cpu_addr, fw->data+offset, ucode_size_bytes); size -= ucode_size_bytes; ptr += ucode_size_bytes; memset_io(ptr, 0, size) - none validated against fw->datasize or BO size. With crafted fw header: memcpy writes ~4GB into ~640KB BO (heap overflow), size-= wraps to huge value, memset_io writes GiB of zeros. amdgpu_ucode_validate (amdgpu_ucode.c:251-260) only checks datasize==hdr->size_bytes. Same class as DF-1673. Root-installed firmware threat model.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-1710 · 3 files| File | Type | Description | Size | |
|---|---|---|---|---|
| VERDICT.md | verdict | source-only confirmation + mechanism + fix | 1.6 KB | ↓ raw |
| fix.diff | suggested-fix | Clamp ucode_size_bytes to bo_size; validate header field offsets against allocat | 996 B | view raw |
| ../fix_build_new.log | build-log | Batch kernel build with new fixes (rc=0, -Werror) | 5.6 MB | ↓ download |
DF-1710 — PoC Verification Verdict
Category: drm (module / HW-gated)
Source: sys/dev/drm/amd/amdgpu/amdgpu_vcn.c:126-209
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 (X86_64_GENERIC, INVARIANTS ON, no SMAP/SMEP/KASLR)
Date verified: 2026-07-25
Verdict: REPRODUCED (source-only confirmation; HW/module-gated)
Mechanism
amdgpu_vcn_sw_init reads ucode_size_bytes etc from firmware header (le32_to_cpu) without validating against bo_size or array bounds. A malicious firmware blob can overflow bo allocation.
In GENERIC kernel build: NO (module / not compiled into X86_64_GENERIC on audit QEMU guest)
Reproduction status
This finding is hardware/module gated: the vulnerable code path requires specific hardware (AMD GPU / radeon / Atheros NIC / RAID controller) or a loadable module not present on the audit QEMU guest. The QEMU guest has no GPU passthrough, no physical NIC/RAID HW, and these modules are not exercised. The bug is therefore confirmed by source-level trace of the cited path:line data flow rather than by a runtime PoC. The cited code, guards (or lack thereof), and types were verified against the audited sys/ tree.
Fix
Clamp ucode_size_bytes to bo_size; validate header field offsets against allocation.
See fix.diff for the standalone git-apply-able unified diff. Validated by applying the 38 new-finding batch diffs (including this one) and building a single X86_64_GENERIC kernel (rc=0, -Werror clean).
Fix verification
fixedVALIDATED: fix.diff applies cleanly + batch kernel build rc=0 -Werror; bug HW/module/runtime-gated, no runtime PoC re-test possible on guest.
VALIDATED: fix.diff applies cleanly + batch kernel build rc=0 -Werror; bug HW/module/runtime-gated, no runtime PoC re-test possible on guest.
Confirmed kernel references
—
Detail
Exploit chain
none
Evidence (decisive lines)
REPRODUCED (source-only): amdgpu_vcn_sw_init reads ucode_size_bytes etc from firmware header (le32_to_cpu) without validating against bo_size or array bounds; malicious firmware blob can overflow bo a
Verified recommended fix
REPRODUCED (source-only): amdgpu_vcn_sw_init reads ucode_size_bytes etc from firmware header (le32_to_cpu) without validating against bo_size or array bounds; malicious firmware blob can overflow bo allocation.
Verdict
REPRODUCED (source-only): amdgpu_vcn_sw_init reads ucode_size_bytes etc from firmware header (le32_to_cpu) without validating against bo_size or array bounds; malicious firmware blob can overflow bo allocation.
No comments yet.