# DF-3652 — verdict narrative

## Finding
ci_populate_mvdd_value returns -EINVAL unconditionally, so MemoryACPILevel.MinMvdd is always programmed as 0 (upstream-inverted success return)

## Kernel references
- `sys/dev/drm/radeon/ci_dpm.c:2341`
- `sys/dev/drm/radeon/ci_dpm.c:2359`
- `sys/dev/drm/radeon/ci_dpm.c:3095`
- `sys/dev/drm/radeon/ci_dpm.c:3099`

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


## Root cause and reasoning

Functional/logic defect (no memory-safety impact). ci_populate_mvdd_value walks the mvdd dependency table, fills voltage->Voltage on a match (2350), then falls through to 'return -EINVAL' at 2359 even on success - the success return was inverted at some point (the 'if (i >= count) return -EINVAL' guard at 2355-2356 already covers the failure case). The only caller (ci_populate_smc_acpi_level, 3095-3099) therefore always takes the error branch and programs table->MemoryACPILevel.MinMvdd = 0: the ACPI memory level is shipped to the SMC without an MVDD floor. Verified byte-for-byte identical in upstream Linux master (torvalds/linux ci_dpm.c) - an upstream-inherited bug, filed as hardening/correctness for the DFly tree. Note the filled value also skips the VOLTAGE_SCALE multiplication and byte order conversion the caller applies on its own path (3099), consistent with the caller's use, so only the return is wrong.

## Exploitability

No direct security impact: with a genuine MVDD control object the ACPI DPM level requests MinMvdd=0 from the SMC - a functional power-management regression (potential memory instability on downclock), not a kernel memory-safety issue.

## Recommended fix
Return 0 from ci_populate_mvdd_value when a matching MVDD entry was found (only -EINVAL when the clock is out of range).
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.