DF-4827 — sw_i2cs[] array-domain mismatch in dce_i2c_sw.c (OOB read → wild write)

File: sys/dev/drm/amd/display/dc/dce/dce_i2c_sw.c Lines: 91-92 (guard), 536 (OOB index), 392 (wild write) Severity: High · Class: CWE-129 improper array-index validation → CWE-787 out-of-bounds write

The bug

get_hw_supported_ddc_line() validates the DDC line number against GPIO_DDC_LINE_COUNT (== 8), but the array it feeds, resource_pool.sw_i2cs[], is sized MAX_PIPES (== 6). DDC lines 6 (VGA pad) and 7 (I2C pad) pass the guard and index past the array into the scalar members of struct resource_pool:

sw_i2cs[6]  aliases { i2c_hw_buffer_in_use, 3B pad, pipe_count }
sw_i2cs[7]  aliases { underlay_pipe_index, stream_enc_count }

Both are read as struct dce_i2c_sw * and are non-NULL garbage on every real pool (e.g. 0x0000000600000000 for pipe_count=6). The subsequent engine->ddc = ddc (dce_i2c_sw.c:392) then performs a wild kernel write to the garbage address.

The sibling HW path guards correctly (if (line < pool->pipe_count), dce_i2c_hw.c:365); only the SW path kept the OLD i2caux guard — whose arrays were sized GPIO_DDC_LINE_COUNT (i2caux.h:67) and for which the bound was correct. The old i2caux engine arrays are [GPIO_DDC_LINE_COUNT], the new DC arrays are [MAX_PIPES] — the guard was not updated with the domain.

en ∈ {6,7} and hw_supported come straight from the GPU's VBIOS tables (bios_parser2.c:395-405 → dc_link_ddc.c:269-276 → hw_translate_dce80.c:190-196), so the trigger is a crafted/mis-declared VBIOS (flashed card, passthrough ROM) or any legitimate board that maps a connector's DDC to the VGA/I2C pad with the HW-assist bit. Entry is any I2C transfer on that link: HPD/detect EDID reads (automatic) or the DRM i2c bus (amdgpu_dm_i2c_xfer, amdgpu_dm.c:3983-4016). Reached on every DM ASIC (dce_i2c.c:46-58 tries the SW engine first).

Reproduce on the guest

./build.sh          # compiles the REAL /usr/src/sys .../dce_i2c_sw.c (-Werror) + probe stubs
./run.sh            # phase 1: kldload -> PANIC; phase 2: patched -> clean NULL

Expected (baseline):

swi2cs: OOB READ pool.sw_i2cs[6] == 0x0000000600000000 (pipe_count=6 << 32 | hw_buf_in_use=0)
swi2cs: FIRING - calling the REAL dce_i2c_acquire_i2c_sw_engine(&pool, &ddc)...
Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0x600000000
fault code             = supervisor write data, page not present
Stopped at  dce_i2c_acquire_i2c_sw_engine+0x59:  movq %rbx,(%r12)   <-- engine->ddc = ddc

Expected (fix.diff applied): swi2cs: acquire returned 0 (NULL = correctly rejected) — no panic, module loads and unloads cleanly.

The only stubbed layer is the GPIO service (dal_ddc_open etc.); its emulated success for en=6 is documented from source in VERDICT.md §3.

DF-4827 — VERDICT

Bottom line

REPRODUCED (in-kernel, real audited code): deterministic wild write → kernel panic in dce_i2c_acquire_i2c_sw_engine(). The faulting instruction is the audited engine->ddc = ddc; (dce_i2c_sw.c:392) writing through the OOB-derived garbage pointer pool->sw_i2cs[6] == 0x0000000600000000. Fix validated behaviorally: with fix.diff (line < pool->pipe_count bound, mirroring dce_i2c_hw.c:365), the same call returns NULL cleanly, no fault, module load/unload clean. The full driver entry (real amdgpu probe → dce_i2c_submit_command on a VGA-pad DDC link) is hardware-gated on this guest (no AMD GPU), but is proven by source trace below.

1. Root cause, line by line

• sys/dev/drm/amd/display/dc/inc/hw/hw_shared.h:37 — #define MAX_PIPES 6
• sys/dev/drm/amd/display/include/gpio_types.h:206-220 — enum gpio_ddc_line ends at GPIO_DDC_LINE_I2C_PAD (=7), GPIO_DDC_LINE_COUNT = 8 (DDC1..6 = 0..5, DDC_VGA = 6, I2C_PAD/VIP = 7).
• sys/dev/drm/amd/display/dc/inc/core_types.h:151 — struct dce_i2c_sw *sw_i2cs[MAX_PIPES]; followed (line 152-157) by bool i2c_hw_buffer_in_use; unsigned int pipe_count; unsigned int underlay_pipe_index; unsigned int stream_enc_count; — i.e. sw_i2cs[6] overlays {i2c_hw_buffer_in_use,3B pad,pipe_count} and sw_i2cs[7] overlays {underlay_pipe_index,stream_enc_count} (offsets proven live by the probe: &sw_i2cs[6] == &i2c_hw_buffer_in_use exactly).
• dce_i2c_sw.c:91-92 — get_hw_supported_ddc_line() rejects only line_found >= GPIO_DDC_LINE_COUNT → 6 and 7 pass.
• dce_i2c_sw.c:536 — engine = pool->sw_i2cs[line]; ← OOB read for line 6/7 → scalar garbage interpreted as struct dce_i2c_sw *.
• dce_i2c_sw.c:538 — if (!engine) return NULL; does NOT save us: the garbage is non-NULL whenever pipe_count != 0 (always true on real pools) or stream_enc_count/underlay_pipe_index != 0.
• dce_i2c_sw.c:541 → 404-417 → 380-395 — dce_i2c_engine_acquire_sw() → dce_i2c_sw_engine_acquire_engine() → dal_ddc_open() succeeds (see §3) → engine->ddc = ddc; (dce_i2c_sw.c:392) writes a valid kernel pointer to the garbage address → supervisor write to unmapped/non-canonical address → page fault → panic (or, if the address were mapped, silent cross-object corruption at (pipe_count << 32)).
• Contrast — the HW sibling of the same driver guards correctly: dce_i2c_hw.c:362-367: if (ddc->hw_info.hw_supported) { enum gpio_ddc_line line = dal_ddc_get_line(ddc); if (line < pool->pipe_count) dce_i2c_hw = pool->hw_i2cs[line]; }. The old-generation i2caux arrays are sized GPIO_DDC_LINE_COUNT (i2caux.h:67), so ITS guard (i2caux.c:287) is correct — the bound was simply not updated when the array domain changed to MAX_PIPES in the new DC engine code.

2. Reachability / threat model

• en (the DDC line) is decided by VBIOS tables: bios_parser2.c:395-405 copies i2c_hw_assist (the I2C_HW_CAP bit) and clk_a_register_index from the ATOM GPIO_I2C table; dc_link_ddc.c:266-276 builds the per-link ddc_pin from it; hw_translate_dce80.c:190-196 (same in dce110/120/dcn10) maps mmDC_GPIO_DDCVGA_A → GPIO_DDC_LINE_DDC_VGA (=6) and mmDC_GPIO_I2CPAD_A → GPIO_DDC_LINE_I2C_PAD (=7).
• Every I2C transfer on such a link reaches the bug: dc_submit_i2c (dc.c:1736-1748) → dce_i2c_submit_command (dce_i2c.c:46-58, SW engine tried first on every DM ASIC) → dce_i2c_acquire_i2c_sw_engine.
• Unprivileged reachability of the transfer itself: EDID reads on hotplug/detect (DRM_IOCTL_MODE_GETCONNECTOR forces detect from any local user on real hardware) and the DRM i2c adapter (amdgpu_dm_i2c_xfer, amdgpu_dm.c:3983-4016).
• Attacker preconditions: control of the GPU VBIOS tables (malicious/flashed GPU, PCIe passthrough with forged ROM — the classic drm firmware-parser threat model) or a legitimately-mapped VGA DDC line with HW assist. No AMD GPU on this audit guest, so the hardware entry could not be exercised.

3. What the harness proves and what is stubbed

The KLD (swi2cs_probe.c) links the real, unmodified audited file (guest /usr/src/sys/.../dce_i2c_sw.c, sha256 75d99a9e… == audited tree) compiled with the amdgpu module's own flags (-Werror, see build.log). It constructs a real struct resource_pool with realistic scalars (pipe_count=6, underlay=-1, stream_enc_count=3 — values left by the resource constructors; dce80_resource.c etc.) and a struct ddc whose pin_data->en = GPIO_DDC_LINE_DDC_VGA, hw_info.hw_supported = true.

Only the GPIO-service functions are stubbed. The stub dal_ddc_open returning GPIO_RESULT_OK for en=6 mirrors the real service: * hw_factory_dce80.c:163-164 — number_of_pins[GPIO_ID_DDC_DATA/CLOCK] = 8 → dal_gpio_service_open's busyness bitmap (gpio_service.c:233-241) covers en=6/7 and the pin create path succeeds; * ddc_regs.h — ddc_data_regs(id)/ddc_clk_regs(id) tables have valid entries for GPIO_DDC_LINE_DDC_VGA; * the probe output itself proves dal_ddc_get_line (real semantics: the en member, gpio_service.c:566-570) yields 6 and that get_hw_supported_ddc_line accepts it.

Everything after the stub is the real audited instruction stream — and it faults at dce_i2c_acquire_i2c_sw_engine+0x59: movq %rbx,(%r12) writing to 0x600000000 (fault code = supervisor write data, page not present), which is exactly engine->ddc = ddc with %r12 = OOB garbage sw_i2cs[6].

4. Exploitability

• The write VALUE is a valid kernel heap pointer (ddc), the write ADDRESS is (pipe_count << 32) | small for line 6 — with pipe_count ∈ {2,3,4,6} the target is one of a few fixed ~0x2..0x6_00000000 addresses: canonical, normally unmapped → reliable panic (local DoS given the VBIOS precondition); silent arbitrary-object corruption only in the unlikely case the target is mapped.
• For line 7 (sw_i2cs[7] = stream_enc_count<<32 | underlay_pipe_index), the address embeds 0xFFFFFFFF low bits when underlay is -1 — non-canonical → GPF.
• Full unpriv→root escalation would additionally require controlling the scalars aliased by the OOB read (pipe_count is fixed per ASIC) — not a practical grooming target; the realistic ceiling is denial of service plus the theoretical mapped-address corruption. High severity rests on the wild-write-into-driver-flow class and the firmware-parser attack surface.

5. Fix validation (behavioral, same harness)

• Baseline (run.log): panic — Stopped at dce_i2c_acquire_i2c_sw_engine+0x59: movq %rbx,(%r12), VA 0x600000000.
• Patched (run.2.log): fix.diff applies clean to the guest's dce copy (patch -p1, "Hunk #1 succeeded at 532"), the module rebuilds with -Werror (build.2.log, compiles the patched real dce_i2c_sw.c), and the same call prints swi2cs: acquire returned 0 (NULL = correctly rejected) — no dal_ddc_open, no fault; module loaded AND unloaded cleanly; guest stayed up (vm.sh status → up).
• fix.diff bound line < pool->pipe_count == the array domain idiom already used by the HW path (dce_i2c_hw.c:365); pipe_count ≤ MAX_PIPES on all pools, so the index is provably in-bounds after the fix; line 6/7 DDC handles gracefully fall back (acquire returns NULL, submit falls to the HW engine which equally rejects, call fails with an error instead of corrupting memory).

6. Negative result notes (what was checked and killed in this file)

• div0 in wait_for_scl_high_sw (dce_i2c_sw.c:104): impossible — dce_i2c_submit_command_sw always calls dce_i2c_sw_engine_set_speed first (:506), which floors clock_delay ≥ 12 (:375-376) → clock_delay_div_4 ≥ 3; ASSERT(speed) is a no-op in release but speed ? speed : DCE_I2C_DEFAULT_I2C_SW_SPEED (:371) handles 0.
• Clock-stretch/SCL waits: bounded — I2C_SW_TIMEOUT_DELAY=3000µs (dce_i2c_sw.h:32); scl_retry_max = 3000/delay → ≈3ms per wait_for_scl_high_sw call, worst ≈27ms/byte, ≈7s per 256-byte EDID transfer on a dead bus — bounded stall (hardening note only, same shape as the pass-1-clean i2caux i2c_sw_engine).
• start_sync_sw SDA-stuck loop (:335-359): bounded by I2C_SW_RETRIES=10.
• GPIO NULL family (DF-4787): dal_gpio_get_value/set_value are NULL-pin-safe (gpio_base.c:74-96 return GPIO_RESULT_NULL_HANDLE); ddc->pin_data/pin_clock are non-NULL by construction (gpio_service.c:428-442); return values ignored in read_bit_from_ddc/write_bit_to_ddc but the defaulted value=0 is protocol-fatal only, not memory-unsafe.
• release_engine_dce_sw/dal_ddc_close (dce_i2c_sw.c:65-71): engine->ddc is always set by a successful acquire before submit; dal_gpio_close tolerates NULL pins (gpio_base.c:220-229), double-close safe.
• payload/length plumbing: i2c_request_transaction_data.length is u32 (dce_i2c_hw.h:235), loops bounded by caller-supplied counts (i2c_write_sw/i2c_read_sw:273-316) — no OOB vs the caller's buffers.

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.