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.