DF-4946 — DCN10 offset_to_id returns success on all DDC-family offsets without writing *id

File: sys/dev/drm/amd/display/dc/gpio/dcn10/hw_translate_dcn10.c:165-189 Family: DF-4943 (dce80) / DF-4945 (dce120) — this is the DCN10 (Raven) twin. Severity: Low (memcorrupt bucket) · CWE-457

Build

gcc -O2 -Wall -Wextra -o harness_dcn10 harness_dcn10.c
gcc -O2 -Wall -Wextra -o harness_fixed harness_fixed.c
gcc -O2 -Wall -Wextra -o harness_mask harness_mask.c   # DF-4947 side-car

Run

./harness_dcn10

Expected

All eight DDC-family register offsets (REG(DC_GPIO_DDC{1..6}_A) = 0x5d91..0x5da5, REG(DC_GPIO_DDCVGA_A) = 0x5da9, REG(DC_GPIO_I2CPAD_A) = 0x5dc1) return true after writing only *en — *id is left untouched (sprayed 0x7b7b7b7b survives). en=6 (DDC_VGA) and en=7 (I2C_PAD) exceed the 6-entry hpd_regs[] of hw_factory_dcn10.c:71-78, so a garbage id == GPIO_ID_HPD(3) decodes into define_hpd_registers → &hpd_regs[6..7] OOB const-array read whose garbage register descriptors then drive MMIO. harness_fixed applies the fix (*id = GPIO_ID_DDC_DATA in every DDC branch) and reports 0 residual violations.

The kernel stage needs a Raven-class ASIC + crafted VBIOS gpio_pin_lut entry (absent in QEMU — 0 AMD devices, env.txt); the deterministic contract violation is proven at unit level with the verbatim function and real DCN10 constants.

DF-4946 VERDICT — reproduced (deterministic unit-level; kernel stage needs Raven HW + crafted VBIOS)

What was run

harness_dcn10.c embeds verbatim copies of offset_to_id and id_to_offset from sys/dev/drm/amd/display/dc/gpio/dcn10/hw_translate_dcn10.c (lines 61-201, 203-388) with the single substitution ASSERT_CRITICAL(x) → printf marker. Constants are the real DCN10 values: DCE_BASE__INST0_SEG2 = 0x34C0 (vega10_ip_offset.h:277) and the mmDC_GPIO_* offsets/BASE_IDX from dcn_1_0_offset.h:10349-10584. Enums are the real gpio_types.h values (GPIO_DDC_LINE_I2C_PAD aliases VIP_PAD = 7; COUNT = 8).

Result (run.log)

• T1: all 8 DDC-family offsets return true with *id untouched (id==0x7b7b7b7b UNTOUCHED on every line). DDC1..6 → en 0..5, DDCVGA → en=6, I2CPAD → en=7. hpd_regs[] in hw_factory_dcn10.c:71-78 has exactly 6 entries (indices 0..5) — en 6/7 are out of bounds.
• T2 (negative): raw mmGPIOPAD-style offset 0x183 (the DF-4942 dce80 deterministic producer) is rejected — DCN10 has no GPIOPAD case, so the cross-domain producer is absent; REG(DC_GPIO_DEBUG) correctly returns false.
• T4 (negative): the HPD branch is well-formed (writes *id, en 0..5).

Consumer chain (source-cited)

1. get_hpd_gpio (core/dc_link.c:96-119) calls dal_gpio_service_create_irq with pin_info.offset/mask taken from the VBIOS atom gpio pin table (dcb->funcs->get_gpio_pin_info, bios_parser2.c:537-539).
2. dal_gpio_service_create_irq (gpio_service.c:143-157) declares enum gpio_id id; uninitialized and passes &id to offset_to_id; on true it forwards the garbage id + DDC-line en to dal_gpio_create_irq.
3. dal_gpio_create_irq (gpio_service.c:366-391) accepts GPIO_ID_HPD; dal_gpio_create → dal_gpio_open_ex → dal_gpio_service_open (gpio_service.c:224-290): busyness[HPD] is 1 uint (number_of_pins[HPD]=6, hw_factory_dcn10.c:186) so is_pin_busy(en=6/7) stays inside the allocation, and if the bit is clear → create_hpd + define_hpd_registers(pin, 6/7).
4. define_hpd_registers (hw_factory_dcn10.c:149-157) evaluates &hpd_regs[en] — OOB read of the 6-entry const array; the garbage struct hpd_registers (register offsets read past the array into adjacent rodata) then drives dal_hw_gpio_open/hw_hpd MMIO programming (wrong-register writes / reads at attacker-uncontrolled MMIO offsets) → misbehavior to panic (dos). The final stage is probabilistic (depends on the uninitialized stack slot decoding to 3).

The primary DDC consumer, dal_gpio_create_ddc (gpio_service.c:408-457), ignores id and hardcodes GPIO_ID_DDC_DATA/CLOCK; with DCN10's ddc_data_regs[8]/ddc_clk_regs[8] (hw_factory_dcn10.c:94-114) and number_of_pins[DDC_*]=8 (hw_factory_dcn10.c:183-184), en 0..7 are in-bounds — so, unlike dce80 (DF-4942), the DDC happy path itself is safe on DCN10. The uninit-*id defect matters only through the IRQ path above.

Why not kernel-stage on this guest

env.txt: 0 AMD PCI devices in the QEMU guest — no amdgpu/DC attach, no VBIOS under test. Same situation as the verified family twins DF-4943/4945; their precedent (unit-level deterministic proof + cited kernel chain) is followed exactly.

Fix validation

fix.diff adds *id = GPIO_ID_DDC_DATA; to all eight DDC-family branches. harness_fixed.c applies the same edit to the embedded copy: every DDC-family success now reports id=0 (WRITTEN), and with id==GPIO_ID_DDC_DATA dal_gpio_create_irq takes its default branch and returns NULL — define_hpd_registers can never be reached with en=6/7 (0 residual violations, FIXEXIT=0). A kernel rebuild cannot alter the output of a userland unit harness; structural validation matches the family precedent (DF-4943/4945 fix_status=validated).

fix.diff applies cleanly?

Authored against the read-only sys/ tree at hw_translate_dcn10.c:165-189; hunks are one-line insertions on distinct case labels — no context drift.

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.