VERDICT — DF-4319

Status: untested (kernel path) / index-reachability-confirmed (guest) Impact: none on this guest (hardware-gated); code defect certain, exploitation requires crafted VBIOS

Reproduced?

Not against the kernel: the indices come from the GPU's VBIOS object tables (parsed by the DC BIOS parser) and the audit guest has no AMD GPU at all (pciconf -l → virtio + generic VGA only; see env.txt).

What was verified:

1. Index reachability proof (df4319.c) built and run on the guest (DragonFly cc 8.3): prints the full matrix of index values the DC core can legitimately produce for each of the three const tables, marking the OOB ones (see run.log): transmitter -1/7/8/9 vs 7 entries; channel-1 -1/6/7 vs 6 entries; hpd_source 6 vs 6 entries.

2. Line-by-line trace (static, cited): - dce80_resource.c:661-678 — dce80_link_encoder_create indexes link_enc_regs[enc_init_data->transmitter] (7 entries, :249-257), link_enc_aux_regs[enc_init_data->channel - 1] (6 entries, :221-228), link_enc_hpd_regs[enc_init_data->hpd_source] (6 entries, :235-242) with no validation. - Provenance: core/dc_link.c:1177-1183 fills the three fields from get_ddc_line() (:964-1004), get_hpd_line() (:925-962) and translate_encoder_to_transmitter() (:1006-1069). All three helpers have default arms returning UNKNOWN/-1 variants, and map legitimate enum values (DDC_VGA, I2C_PAD, TRAVIS_*, UNIPHY_G) that exceed the dce80 table bounds. Enums live in include/grph_object_defs.h:45-94 (TRANSMITTER_UNKNOWN = -1; TRAVIS_CRT=7, TRAVIS_LCD=8, UNIPHY_G=9; CHANNEL_ID_DDC_VGA=7, I2C_PAD=8; HPD_SOURCEID_UNKNOWN=6). - Dereference sites of the stored OOB pointers: dce_link_encoder.c:494 and :501 (AUX_REG(...) → dm_read_reg/dm_write_reg) and :1370/:1384 (HPD_REG(DC_HPD_CONTROL) → dm_read_reg/dm_write_reg).

Impact ceiling

Register addresses are read from static data adjacent to the const tables (&arr[-1] / &arr[6..8] land in neighboring .data/.rodata), then used for MMIO reads and writes. With a crafted VBIOS (physical access / VBIOS flash / PCIe device spoofing) this is semi-controlled MMIO corruption; on stock hardware the realistic outcome for an unknown-encoder/VGA-DDC/no-HPD connector object is programming garbage register offsets → display engine misbehavior or hang. No path from an unprivileged local user was found that influences these values (they never traverse userspace).

Calibration: same family and severity as DF-4312 (dcn10, Low, AV:P).

Exploit chain

Physical/VBIOS prerequisite ⇒ none from an unprivileged user. Chain for a VBIOS-controlling attacker: choose encoder object id/enum_id and DDC/HPD GPIO lines in the ROM object table → pick which adjacent static data is read as the register base → MMIO write with partially chosen 32-bit value at dm_write_reg(ctx, addr, value) during link encoder setup / HPD enable-disable. Deterministic per-VBIOS, but hardware-bound.

Fix validation

fix.diff adds explicit range checks before the three lookups (transmitter ∈ [0,6], channel ∈ DDC1..DDC6, hpd ∈ HPD_SOURCEID1..6) and frees enc110/returns NULL on violation; caller handles NULL gracefully (dc_link.c:1187-1189 → link_enc_create_fail). Not kernel-tested — no hardware on the guest.

Conclusion

Missing validation is certain; exploitation is hardware/physical-gated ⇒ Low severity, confidence "likely".

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.