DF-3890 — vid_mapping_table->entries[num_entries - 1] with num_entries == 0 → wild read (~+16 GB) in kv_convert_vid2_to_vid7

File: sys/dev/drm/amd/amdgpu/kv_dpm.c:90 (primary sink; identical pattern at :114 in kv_convert_vid7_to_vid2) Class: CWE-191 unsigned count-1 underflow → wild OOB read (boot-time panic) Verdict: inconclusive at runtime on this guest (no AMD GPU); source-certain; harness proves index/offset and SIGSEGV on the verbatim read.

Build (on the DragonFly guest, as root)

mkdir -p /tmp/DF-3890 && cp vid_mapping_zero_entries.c /tmp/DF-3890/h.c
cd /tmp/DF-3890 && cc -Wall -O0 -o t h.c

Run

./t          # accounting — index and byte offset
./t crash    # verbatim read -> SIGSEGV (exit 139)

Expected

• accounting: num_entries = 0; entries[4294967295]; byte offset 4294967295 * 4 = 17179869180 (~17.2 GB) past the 16-byte array.
• crash: Segmentation fault, exit=139 (kernel equivalent: page fault in kernel mode → panic).

Kernel trigger (all VBIOS-controlled, parse-legal)

1. sAvail_SCLK[] has strictly-increasing nonzero ulSupportedSCLK (so num_max_dpm_entries > 0 and the guard at kv_dpm.c:2040 passes) but usVoltageID == 0 on every entry → sumo_construct_vid_mapping_table leaves every vid_7bit zero → compaction breaks at i == 0 → num_entries = 0 (kv_dpm.c:185-190).
2. PowerPlayInfo has no VddcDependencyOnSCLK subtable (count == 0) → the else branch at kv_dpm.c:86-91 is taken.

Boot path: kv_dpm_init → kv_parse_sys_info_table (:2617) → kv_construct_max_power_limits_table (:2045) → kv_convert_2bit_index_to_voltage (:690) → kv_convert_vid2_to_vid7 (:90). Also reached later from kv_init_graphics_levels (:2453) in the same count == 0 configuration.

DF-3890 — verdict narrative

Finding

kv_convert_vid2_to_vid7 (kv_dpm.c:72-92) falls back to the firmware-built mapping table when vddc_dependency_on_sclk.count == 0 (no SCLK dep subtable in the PowerPlayInfo header — amdgpu_parse_clk_voltage_dep_table is only invoked when usVddcDependencyOnSCLKOffset != 0, amdgpu_dpm.c:384-395):

} else {
        for (i = 0; i < vid_mapping_table->num_entries; i++) {
                if (vid_mapping_table->entries[i].vid_2bit == vid_2bit)
                        return vid_mapping_table->entries[i].vid_7bit;
        }
        return vid_mapping_table->entries[vid_mapping_table->num_entries - 1].vid_7bit;  /* :90 */
}

num_entries is produced by sumo_construct_vid_mapping_table (:159-191) as the index of the first zero vid_7bit run after compaction. If every usVoltageID in the VBIOS sAvail_SCLK[] is 0 (while ulSupportedSCLK values are nonzero and strictly increasing — needed so num_max_dpm_entries > 0), all vid_7bit stay 0, the compaction breaks at i == 0, and num_entries == 0. Then :90 evaluates entries[(u32)0 - 1] = entries[0xFFFFFFFF] = entries + 17,179,869,180 bytes (~16 GiB) — a wild read, page fault → panic.

Reach (boot, before any power-state machinery): kv_dpm_init (:2848) → kv_parse_sys_info_table (:2617) → kv_construct_max_power_limits_table (:2040-2046: num_max_dpm_entries > 0 is checked, num_entries is not) → kv_convert_2bit_index_to_voltage (:690) → sink. Also later from kv_init_graphics_levels else-branch (:2453, kv_set_vid).

The identical entries[num_entries - 1] pattern exists at :114 (kv_convert_vid7_to_vid2); its callers currently take the count != 0 branch (kv_init_graphics_levels :2433), so :90 is the live instance.

Distinct from DF-3887 (same source table, but that is the write with an out-of-range usVoltageIndex; this is the read underflow when the table ends up empty) and from DF-1268/1269 (count overflow / parse indices).

Root cause (kernel references)

• sys/dev/drm/amd/amdgpu/kv_dpm.c:90 — underflowed index read
• sys/dev/drm/amd/amdgpu/kv_dpm.c:114 — identical pattern (latent)
• sys/dev/drm/amd/amdgpu/kv_dpm.c:185-190 — num_entries can legitimately be 0
• sys/dev/drm/amd/amdgpu/kv_dpm.c:2045 / :690 — reachable call chain
• sys/dev/drm/amd/amdgpu/amdgpu_dpm.c:384-395 — count==0 is parse-legal

What was verified, and how

1. Source-level certainty. Full-file pass-2 audit; compaction logic walked for the all-zero-usVoltageID case; the count == 0 else-branch selection verified against amdgpu_parse_extended_power_table.
2. Harness on the guest (DragonFly 6.5-DEVELOPMENT x86_64, base cc 8.3): vid_mapping_zero_entries.c replicates the function verbatim; accounting mode prints entries[4294967295] / +17179869180 bytes (~17.2 GB); crash mode executes the verbatim read against a single-page mapping → SIGSEGV exit=139 (kernel equivalent: page fault in kernel mode → panic).
3. Hardware absence. Guest is virtio-only; trigger needs a KV APU + crafted VBIOS. Recorded inconclusive, impact none on this guest; source + harness certain.

Fix validation

fix.diff guards num_entries != 0 at both :90 and :114 (returning 0 otherwise). Not built on the guest (no AMD hardware) → fix_status: not_testable.

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.