DF-4942 — hw_translate_dce80.c: GPIOPAD decode leaks en≤30 into the 8-entry DDC register arrays (OOB read → wild MMIO programming)

File audited (pass 2): sys/dev/drm/amd/display/dc/gpio/dce80/hw_translate_dce80.c Lines: 164-167 (mmGPIOPAD_A case), 172-196 (DDC cases with no *id), consumer chain in gpio_service.c:408-457, hw_factory_dce80.c:84-104,114-137.

What to run

./build.sh          # compiles harness_dce80.c (verbatim copy of offset_to_id/id_to_offset,
                    #  real DCE8 register constants) and the fixed variant
./run.sh            # runs both; see run.log (baseline) and fixrun.log (after fix.diff)

Expected (baseline, reproduced on the DF 6.5-DEVELOPMENT guest, gcc 8.3)

== T2: GPIOPAD offset succeeds with en up to 30 (DF-4942 producer) ==
offset_to_id(mmGPIOPAD_A,1<<20) = true id=GPIO_ID_GPIO_PAD(4) en=20
  -> BUG(DF-4942): success with en=20 >= 8 entries: define_ddc_registers reads
     ddc_data_regs[20] OOB (hw_factory_dce80.c:122), regs then drive MMIO

T3 (negative control) in the same output proves the GPIOPAD bound inside offset_to_id is sound (31/UNKNOWN=32/multi-bit rejected) — the defect is the cross-domain hand-off, not the internal bound.

Expected (after fix.diff)

  -> FIXED: translate still decodes en=20, but fixed consumer guard
     (id != GPIO_ID_DDC_DATA) rejects: accepted=0 -> no ddc_data_regs[20] OOB
0 regressions after fix (expect 0)

Full kernel chain (code-trace; not executable in QEMU — no AMD ASIC)

1. VBIOS ATOM_GPIO_I2C_INFO.asGPIO_Info[line].usClkA_RegisterIndex (arbitrary u16, bios_parser.c:1881-1882) → dal_gpio_create_ddc(svc, 0x183 /*mmGPIOPAD_A*/, 1<<shift, …) (dc_link_ddc.c:272-276).
2. offset_to_id(0x183, 1<<shift) → true, *id=GPIO_ID_GPIO_PAD, *en=shift∈[0..30] (hw_translate_dce80.c:164-167).
3. dal_gpio_create_ddc ignores id and creates GPIO_ID_DDC_DATA/CLOCK gpio objects with en (gpio_service.c:418-437).
4. First DDC use → dal_gpio_service_open → define_ddc_registers(pin, en) → ddc_data_regs[en] / ddc_clk_regs[en] — arrays of 8 entries (hw_factory_dce80.c:84-104) → for en 8..30 an OOB read of const .rodata, pointer-stored into ddc->regs/ddc->base.regs (hw_factory_dce80.c:122-127).
5. pin->funcs->open/set_config → REG_UPDATE/REG_GET on regs->… (hw_ddc.c/hw_gpio.c reg_helper) → MMIO R/W at garbage register offsets → panic/MCE or wrong-register corruption of display-block state.

Impact ceiling

Deterministic OOB (no uninitialized-stack dependency) given one crafted u16 in the VBIOS image at amdgpu attach. Not reachable by an unprivileged user on stock hardware (VBIOS is GPU firmware); realistic preconditions: re-flashed VBIOS, corrupted firmware, or a host-supplied ROM in GPU-passthrough setups. Impact: kernel panic / device-state corruption (DoS class). No RAM write primitive (addresses land in MMIO space).

DF-4942 VERDICT

Status: reproduced (unit-level, verbatim function copy executed on the DF guest); kernel chain proven by code trace — full execution requires an AMD ASIC + crafted VBIOS, which the QEMU guest does not have.

What was proven, and how

• The audited functions index_from_vector, offset_to_id, id_to_offset were copied verbatim from sys/dev/drm/amd/display/dc/gpio/dce80/hw_translate_dce80.c:44-400 into harness_dce80.c, with the real register constants from dce_8_0_d.h/dce_8_0_sh_mask.h/smu_7_0_1_d.h and the real enum values from gpio_types.h. Compiled with gcc 8.3 (-O2 -Wall -Wextra, zero warnings) and executed on the DragonFly 6.5-DEVELOPMENT guest.
• Output (run.log): offset_to_id(mmGPIOPAD_A, 1<<20) returns true with id=GPIO_ID_GPIO_PAD(4), en=20. 20 ≥ 8 = the number of entries in ddc_data_regs[]/ddc_clk_regs[] (hw_factory_dce80.c:84-104). That is the exact decode result the kernel consumer receives.
• Negative controls (T3): 1<<31 → false (31 > GPIO_GPIO_PAD_MAX=30), multi-bit mask → false (GPIO_ENUM_UNKNOWN=32 > 30), zero → false. The internal GPIOPAD bound is sound; the defect is that success is reported in a call context whose only consumer (dal_gpio_create_ddc, gpio_service.c:408-457) discards *id and interprets en in the gpio_ddc_line domain (8 entries).

Kernel chain (traced, path:line)

bios_parser.c:1881 (usClkA_RegisterIndex, arbitrary VBIOS u16; equals mmGPIOPAD_A=0x183 on the DCE8 input path — smu_7_0_1_d.h:138) → dc_link_ddc.c:272-276 (dal_gpio_create_ddc(gpio_service, 0x183, 1<<shift, …)) → gpio_service.c:418-419 offset_to_id success, 428-437 creates DDC_DATA/DDC_CLOCK gpio objects with en (id output ignored) → first DDC use gpio_base.c:59-72 dal_gpio_open_ex → gpio_service.c:244-253 create_ddc_data + define_ddc_registers(pin, en) → hw_factory_dce80.c:122 ddc->regs = &ddc_data_regs[en] — OOB const-array read for en ∈ [8..30] — → hw_ddc.c/hw_gpio.c use regs->… addresses for REG_UPDATE/REG_GET MMIO (garbage offsets from adjacent .rodata: likely ddc_clk_regs[0..] for en 8..15 — wrong-but-in-layout register descriptors; beyond that, shift/mask constants reinterpreted as register addresses → unmapped MMIO → panic/MCE).

Related already-filed finding (consumer side, different array): DF-4827 (dce_i2c_sw.c sw_i2cs[MAX_PIPES=6] vs GPIO_DDC_LINE_COUNT=8). DF-4942 is the translate-side producer defect for a different consumer array pair (ddc_data_regs/ddc_clk_regs, 8 entries) with the GPIOPAD domain (en≤30) as the OOB source — not a re-report.

Why not executed end-to-end

Guest has no AMD GPU (pciconf: 0 devices vendor 0x1002; amdgpu module not loaded — env.txt). The VBIOS→GPIO path only executes on real ASICs at driver attach. The deterministic producer stage was executed verbatim instead; the consumer stage is a four-hop straight-line trace with no branches that could change the outcome (en is passed unmodified: create_ddc_data(ctx,id,en) → define_ddc_registers(pin,en) → array index).

Fix validation

fix.diff (3 files: dce80 translate sets *id=GPIO_ID_DDC_DATA on all 8 DDC cases; dce120 same; gpio_service.c:dal_gpio_create_ddc rejects id != GPIO_ID_DDC_DATA) — git apply --check clean; harness_fixed.c models the fixed translate + consumer guard: en=20 decode now rejected at the consumer (accepted=0), 0 regressions, T4/T5 behaviors preserved (fixrun.log).

Impact

Medium. DoS-class (panic/wrong-register MMIO) at driver attach with a crafted/corrupt VBIOS; not unprivileged-user-reachable on stock hardware.

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.