# DF-4200 VERDICT — NULL function-pointer call at amdgpu_connectors.c:1387

**Verdict: not reproduced at runtime (hardware-gated); source-level
certainty: certain. Impact if exercised on affected hardware: kernel panic
(DoS).**

## The chain, line by line

1. `amdgpu_connector_dp_detect()` runs for every DP-family connector on
   every probe (HPD poll `amdgpu_irq.c:80-94` → connector detect; or
   userspace `DRM_IOCTL_MODE_GETCONNECTOR`).
2. `encoder = amdgpu_connector_best_single_encoder(connector)`
   (amdgpu_connectors.c:1335) returns the first entry of the connector's
   possible-encoder list.
3. Possible encoders are attached by `amdgpu_link_encoder_connector()`
   (amdgpu_encoders.c:45-56) walking `mode_config.encoder_list` — the order
   in which `dce_v*_0_encoder_add` created them from the ATOMBIOS encoder
   object table.
4. For a DP-bridge connector (Travis/Nutmeg — the exact devices listed at
   amdgpu_connectors.c:1547-1550), the encoder list contains both the
   external bridge encoder and the internal UNIPHY encoder, in BIOS order.
5. External bridge encoders get `dce_v{8,10,11}_0_ext_helper_funcs`, which
   have **no `.detect`** (dce_v10_0.c:3411-3418 — source comment "no detect
   for TMDS/LVDS yet"; same in dce_v8_0.c:3299, dce_v11_0.c:3537).
6. If the bridge encoder is first (or is the only one whose devices mask
   overlaps), and the aux/DDC probe at :1383 fails (unplugged adapter), and
   `dac_load_detect` is true (default **true** for DP-bridge VGA/DVI-I
   connectors — set at :1599 and :1646 during `amdgpu_connector_add`),
   then :1387 `encoder_funcs->detect(encoder, connector)` is a call through
   a NULL function pointer → immediate kernel panic.
7. The same file guards this exact pattern at :1082-1083
   (`if (encoder_funcs->detect)`) — the guard at :1387 was simply omitted.

## Runtime attempt

`trigger_df4200.c` (raw ioctl, self-contained struct definitions) built
cleanly with the guest cc 8.3 and ran; the guest exposes no DRM device
(`/dev/dri` absent, QEMU virtual display only, no AMD/ATI PCI devices —
`env.txt`), so `amdgpu_connector_dp_detect` cannot be entered: the
deterministic trigger needs a Travis/Nutmeg bridge laptop with the bridge
encoder enumerated first in its VBIOS object table, plus a failing DDC
probe. Classification mirrors the radeon twins (DF-4033..4035):
`not_reproduced` at runtime, `certain` at source level.

## Why not a false positive

- `.detect` absence is deliberate and documented in-source for ext
  encoders; only TMDS ext encoders exist for the bridge IDs referenced.
- The guard exists in the sibling path — this is not a "detect can never be
  NULL" invariant.
- BIOS object-table order determines the first possible encoder; nothing
  in the driver reorders possible encoders (drm_connector_attach_encoder
  appends; amdgpu_encoders.c:45-56 iterates in list order).

## Fix validation

Not possible on this guest (no AMD GPU). `fix.diff` mirrors the in-file
guard at :1083 and is compile-checked against the tree (applies cleanly,
`patch --dry-run` verified locally against the read-only sys/ tree).

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