# DF-4910 — Unsynchronized `aconnector->dc_sink` teardown race between `dm_dp_destroy_mst_connector` (unlocked) and `dm_dp_mst_get_modes` (under mode_config.mutex)

File: `sys/dev/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c`
Severity: Medium | CWE-362 / CWE-367 | confidence: likely

## What to build / run

The kernel-side race requires AMD Display Core hardware with a DisplayPort MST
topology (amdgpu DM + a DP hub or MST monitor). The userspace half of the race
is `mst_race_trigger.c` (hammer `DRM_IOCTL_MODE_GETCONNECTOR`); the other half
is an MST topology change (unplug/re-enumeration of the hub), which only
hardware can produce.

```
./build.sh    # cc -o mst_race_trigger mst_race_trigger.c  (on a machine WITH /dev/dri)
./run.sh      # loop: open card, enumerate connectors, hammer GETCONNECTOR
              # while the DP-MST topology is flapped (unplug hub / power-cycle dongle)
```

## Expected result (on AMD MST hardware)

- `run.log` on the kernel console after 1..4 successful races shows, on the
  next monitor connect, the DF-1966 signature:
  `dc_link_add_remote_sink` permanently returning NULL (all
  `MAX_SINKS_PER_LINK`(4) slots leaked) -> `dc_sink->priv = aconnector`
  NULL-deref panic in `dm_dp_mst_get_modes` (amdgpu_dm_mst_types.c:243).
- Between races: leaked `dc_sink` objects pinned in `link->remote_sinks[]`
  with `->priv` pointing at the freed `amdgpu_dm_connector`.

## Actual result on this audit guest

The audit guest (DragonFly 6.5-DEVELOPMENT, QEMU/KVM) has **no AMD PCI display
device** (only the QEMU virtual VGA `vgapci0`, chip 0x1234 8086-class), so
`amdgpu.ko` loads but binds nothing: no `/dev/dri`, no connectors, the
`dm_dp_mst_*` code paths are unreachable at runtime. Recorded honestly in
`run.log` / `env.txt`. Status: **untested** (hardware-gated), root cause fully
proven by source trace (see VERDICT.md).