# DF-4621 VERDICT

## Finding
OR-combined `valid_input` in `dp_link_settings_write`
(amdgpu_dm_debugfs.c:195-221) accepts an invalid lane_count whenever the
link_rate is valid; the lane_count is stored unvalidated
(dc/core/dc.c:484) and later drives:
- the `lane_settings[r]` write loop in `dp_phy_settings_write`
  (amdgpu_dm_debugfs.c:403) — array is `lane_settings[LANE_COUNT_DP_MAX=4]`
  (link_service_types.h:71-75, dc_dp_types.h:37) → stack OOB write
  (12 bytes per extra lane; unbounded for lane_count=0xffffffff);
- `decide_link_settings` (dc_link_dp.c:1517-1525) — verbatim propagation
  into link training (LIVE dc code; its only corrupting producer is this
  dead debugfs file).

## Status: untested (kernel path), logic-proven (guest demo)
- The kernel path CANNOT run on this guest for two independent reasons:
  1. `amdgpu_dm_debugfs.c` is **not compiled** in DragonFly: absent from
     `sys/dev/drm/amdgpu/Makefile` SRCS (:195-201); callers #if'd under
     CONFIG_DEBUG_FS (amdgpu_dm.c:478,4119) which kconfig.h does not define.
  2. The guest has no AMD GPU (env.txt: no AMD PCI devices) — amdgpu DM
     never attaches.
- Supporting runtime logic-proof on the guest (`dp_link_logic_demo.c`,
  transcription of :195-221 and :394-410 with the real constants): input
  "5 a" → ACCEPTED, lane_count=5 stored, consumer loop performs iteration
  r=4 writing past lane_settings[3] — gcc corroborates with
  `-Waggressive-loop-optimizations: iteration 4 invokes undefined behavior`
  (demo_run.log). This demonstrates the validation flaw at runtime but is
  NOT a kernel execution; verdict status remains `untested` honestly.

## Exploitability (if the file is ever built, i.e. enable-day)
Preconditions: AMD display hardware + CONFIG_DEBUG_FS build + the file added
to SRCS + root-writable... actually /sys/kernel/debug/dri files are 0644
(:712) — world-writable from the DRM master's context; debugfs is root-only
mounted (debugfs root, 0700 typically) → effectively a root-or-console
trigger, EXCEPT the invalid lane_count persists in `link->preferred_link_
setting` and `decide_link_settings` (live path) then walks it during
unprivileged-triggerable modesets. Even then written values are enum triples
{0..3} per 4-byte slot → crash-grade corruption, not clean pointer control;
lane_count=0xffffffff gives an unbounded low-value stack smash → panic.
Severity kept at Medium *because* it is latent (project precedent: dead-code
findings DF-1764/1765/DF-4554 = Low; this one is an OOB **write** primitive,
flagged for anyone enabling the debugfs build).

## Fix
fix.diff (mechanically generated, applies to the tree as-is): split
valid_lane_count / valid_link_rate, require both.

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