# DF-3649 — verdict narrative

## Finding
Wild OOB kernel read in ci_get_std_voltage_value_sidd when the CAC leakage table count is 0: idx = (u16)(count-1) = 65535 past a ZERO_LENGTH_PTR that passes the entries!=NULL guard

## Kernel references
- `sys/dev/drm/radeon/ci_dpm.c:2362`
- `sys/dev/drm/radeon/ci_dpm.c:2374`
- `sys/dev/drm/radeon/ci_dpm.c:2379`
- `sys/dev/drm/radeon/ci_dpm.c:2382`
- `sys/dev/drm/radeon/ci_dpm.c:2384`
- `sys/dev/drm/radeon/ci_dpm.c:2396`
- `sys/dev/drm/radeon/r600_dpm.c:1039`
- `sys/dev/drm/radeon/r600_dpm.c:1063`
- `sys/kern/kern_slaballoc.c:193`
- `sys/kern/kern_slaballoc.c:886`

## Was it reproduced?
No — not on the kernel path. The audit guest is virtio-only (0 AMD PCI devices, /dev/dri absent, no radeon/drm kld; env.txt), so `sys/dev/drm/radeon/ci_dpm.c` can never execute there. Per the pass-2 instruction for this hardware-gated file, the verdict is **inconclusive** (source-level certainty certain) rather than reproduced.

## Logic-level proof (guest harness)
harness.c models the exact loop/index/division with the exact kernel types and was compiled and executed on the audit guest (`cc -O2 -Wall`, DragonFly 6.5-DEVELOPMENT). Decisive output, stable across 2 runs (run.log, run.2.log):

    count=0 -> idx=65535; wild read address 0x7fff0 (unmapped)


## Root cause and reasoning

Source-certain wild read, radeon/ci twin of DF-3587 (amdgpu) / DF-3620 (amdgpu ci). r600_parse_extended_power_table allocates cac_leakage_table.entries with kzalloc(ucNumEntries * entry_size) (r600_dpm.c:1039-1040) and sets count = ucNumEntries (1063). With a crafted usCACLeakageTableOffset whose table declares 0 entries, DragonFly kmalloc(0) returns ZERO_LENGTH_PTR == (void *)-8 (kern_slaballoc.c:193, 886-890) - NON-NULL - so the entries!=NULL guard at ci_dpm.c:2374 passes. The match loops then compute idx = rdev->pm.dpm.dyn_state.cac_leakage_table.count - 1 (ci_dpm.c:2382, 2399); with count==0 the u32 0-1 truncated into u16 idx yields 65535, and entries[65535].vddc / .leakage (2384-2386, 2401-2403) reads ~512KB past a 0-byte allocation - unmapped kernel VA -> page fault/panic (or uncontrolled kernel-memory read if the address happens to be mapped). Requires voltage_control != NONE and any vddc match in vddc_dependency_on_sclk (count>=1 enforced by ci_setup_default_dpm_tables). On-guest harness section [D] demonstrated idx=65535 and the resulting wild address. Kernel path unreachable on this GPU-less guest; inconclusive overall.

## Exploitability

Crafted VBIOS: SVID2/GPIO VDDC voltage object + a CACLeakageTable with ucNumEntries=0 (kzalloc(0) -> ZERO_LENGTH_PTR passes the non-NULL guard) + any sclk dependency entry whose voltage matches/eclipses the SVI2 table value -> entries[65535] wild read. Primary impact panic; if the wild address were mapped the read leaks into StdVoltageHiSidd/LoSidd which are shipped to the SMC (not directly userspace-visible). DoS-grade.

## Recommended fix
Require entries != NULL AND count > 0 before using the CAC leakage table in ci_get_std_voltage_value_sidd.
See fix.diff.

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