# DF-4375 VERDICT

**Status: inconclusive** (defect certain from source; kernel-path runtime
manifestation requires AMD DCE112 hardware that the verification guest does not
have — same classification as twin DF-4312).

## Reproduced? How?

1. **Source trace (certain).** The three const-table indexings at
   `dce112_resource.c:577-579` have no range validation. The index values are
   produced by the DC core itself from the VBIOS object tables:
   - `enc_init_data.transmitter` — `translate_encoder_to_transmitter()`
     (`core/dc_link.c:1006-1071`): returns `TRANSMITTER_UNKNOWN(-1)` for any
     unrecognized encoder id/enum pair (multiple `default:` arms), and
     `TRANSMITTER_UNIPHY_G(9)` / `TRAVIS_CRT(7)` / `TRAVIS_LCD(8)` for
     `ENCODER_ID_INTERNAL_UNIPHY3` / `EXTERNAL_TRAVIS` entries a VBIOS can
     carry. → `link_enc_regs[-1|7|8|9]` into a 7-entry array.
   - `enc_init_data.channel` — `get_ddc_line()` (`core/dc_link.c:964-1004`):
     returns `CHANNEL_ID_UNKNOWN(0)` (→ `aux_regs[-1]`), `CHANNEL_ID_DDC_VGA(7)`
     (→ 6), `CHANNEL_ID_I2C_PAD(8)` (→ 7) into a 6-entry array.
   - `enc_init_data.hpd_source` — `get_hpd_line()` (`core/dc_link.c:925-962`):
     returns `HPD_SOURCEID_UNKNOWN(7)` when the connector has no HPD GPIO or an
     unmapped IRQ source → `hpd_regs[7]` into a 6-entry array. This one is
     reachable with an entirely *well-formed* VBIOS entry that merely lacks an
     HPD mapping — no crafted values needed.
2. **Index-arithmetic proof on the guest (ran, deterministic).**
   `df4375_poc.c` mirrors the arrays with their exact element counts and drives
   the exact index expressions with the exact enum values above
   (`build.log`, `run.log`, `env.txt`). Every DC-legitimate out-of-range value
   lands past the table end. The plain (non-ASan) build actually performs the
   OOB reads without trap — as does the kernel, silently.
3. **ASan attempt:** `cc -fsanitize=address` fails on the guest — GCC 8.3
   DragonFly has no `libasan` (`build.log` first attempt recorded in
   VERDICT-notes; final build used plain mode).

## Why not `reproduced` (kernel)

`dce112_link_encoder_create` runs only during amdgpu driver bind on a Polisas
(DCE112) ASIC. Guest `pciconf -l` shows only QEMU/virtio devices; there are
**0 AMD (0x1002) PCI devices**, so the amdgpu KLD (present in the tree at
`sys/dev/drm/amd/amdgpu/Makefile`) never attaches and `construct()` is never
reached. No unprivileged-software trigger exists: the only inputs are the GPU's
own VBIOS tables, i.e. the attacker model is a crafted/flashed VBIOS or
malicious DP-dock silicon enumerating TRAVIS/NUTMEG-class encoders — identical
to the accepted twins DF-4312 (dcn10), DF-4319 (dce80), DF-4352 (dce110).

## Impact

OOB reads of adjacent .rodata/.data; the garbage `struct ..._registers` becomes
the link encoder's permanent register base, so subsequent `REG_UPDATE/AUX`
paths compute MMIO offsets from unrelated memory → wild MMIO reads/writes on
the GPU BAR. Realistic ceiling: display pipeline misconfiguration / firmware
misbehavior / system hang on the affected machine; not a remote or unprivileged
local primitive. Severity Low (hardware + malicious-firmware precondition),
bucket kernleak — consistent with the twins.

## Exploit chain

None developed — no path from unprivileged input; requires attacker-controlled
GPU firmware/VBIOS. Chain stops at "crafted VBIOS → wild MMIO offsets".

## Fix validation

`fix.diff` adds an explicit range check (unsigned-compare idiom rejects both the
-1 sentinels and the above-range values) and returns NULL, which the caller
already handles gracefully (`core/dc_link.c:1184-1189` → `link_enc_create_fail`
→ link construction fails cleanly). `git apply --check` passes against `sys/`
(not applied; sys/ is read-only for this audit). Kernel build/run validation
impossible on this guest (no AMD GPU), so `fix_status: not_testable` — the fix
is 4 statements of trivially-compilable C (ARRAY_SIZE/kfree only), same
classification as twins DF-4319/DF-4352.

## Guest hygiene

Guest left up, untouched (only /root scratch files). `guest_dirty: 0`.

## 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.