# VERDICT — DF-4359

**status: untested** (runtime PoC impossible on the audit guest — hardware-gated) ·
**impact (demonstrated): none** · confidence: certain (static proof).

## Reproduced?

No — and it cannot be on this guest: exercising the path requires a CIK AMD ASIC
(Bonaire/Hawaii/Kaveri/Kabini/Mullins) so the amdgpu cik_sdma IP block instantiates.
Guest check (2026-09-19): `pciconf -l` on DragonFly 6.5-DEVELOPMENT x86_64 (QEMU/KVM)
shows no AMD (0x1002) PCI device; `cik_sdma_init_microcode` is unreachable at runtime.
No kernel build/test was performed; this is a pure code-correctness defect proven from
source:

- cik_sdma.c:141 — `err = amdgpu_ucode_validate(...)` result is never branched on
  inside the loop; only the *last* iteration's result reaches the `out:` handler.
- With num_instances == 2 (cik_sdma.c:950): instance-0 validate failure (-EINVAL) is
  overwritten by instance-1 success (0) → function returns 0 keeping an unvalidated
  blob in adev->sdma.instance[0].fw.
- amdgpu_ucode.c:251-260 — validate is the only gate (`datasize == hdr->size_bytes`);
  a blob failing it is exactly one whose header is internally inconsistent.
- Downstream sink (already known as DF-1553): cik_sdma.c:552-565 consumes
  ucode_size_bytes / ucode_array_offset_bytes with no bounds check → OOB kernel read
  streamed into GPU registers via WREG32 loop; amdgpu_ucode_print_sdma_hdr formats the
  garbage header.

DF-4359 is DISTINCT from DF-1553: different function (init vs load), different root
cause (dropped error propagation vs missing bounds math), different fix. Fixing
DF-1553 alone leaves DF-4359 admitting firmware that even the weak check rejects.

## Exploit chain

Not applicable: firmware placement requires root (same trust model that graded
DF-1553/DF-1673 Low). Ceiling: OOB kernel-memory read into GPU registers / dmesg.

## Fix validation

not_testable — no CIK hardware on the guest to build/boot a patched kernel against.
The one-line fix (branch on err immediately after cik_sdma.c:141) is mechanically
identical to the request_firmware check two lines above; regression risk ~zero.

## 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.

(No fix.diff for this item: documented recommendation only - see Fix above.)