DF-4621 — amdgpu_dm debugfs: OR-combined valid_input accepts invalid lane_count → stack OOB write in dp_phy_settings_write (LATENT: file not compiled)

What

dp_link_settings_write() validates the two user parameters with a single OR-combined flag (sys/dev/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c:195-221):

    switch (param[0]) {          /* lane_count */
    case LANE_COUNT_ONE: ... valid_input = true; ...
    switch (param[1]) {          /* link_rate */
    case LINK_RATE_LOW: ... valid_input = true; ...   /* same flag! */
    if (!valid_input) { ... return; }

echo "5 a" > link_settings (or echo ffffffff a) passes with an invalid lane_count because the link_rate matched. The value is then stored unvalidated into link->preferred_link_setting by dc_link_set_preferred_link_settings() (dc/core/dc.c:484), and consumed:

1. dp_phy_settings_write (:386-410) — when test_pattern_enabled, link_lane_settings.link_settings.lane_count = link->preferred_link_setting.lane_count, then for (r = 0; r < lane_count; r++) link_lane_settings.lane_settings[r] = … writes past lane_settings[LANE_COUNT_DP_MAX = 4] (include/link_service_types.h:71-75; LANE_COUNT_DP_MAX = LANE_COUNT_FOUR, dc/dc_dp_types.h:37). lane_count=5 → 12-byte stack overrun; lane_count=0xffffffff → unbounded linear stack smash (values constrained to enum triples 0..3 per 4-byte slot). link_lane_settings is a local — stack OOB write (CWE-787).
2. decide_link_settings() (dc/core/dc_link_dp.c:1517-1525, live code) returns *link_setting = link->preferred_link_setting verbatim → invalid lane_count propagates into link training (lt_settings.lane_settings[] walks, DPCD lane writes).

Liveness (verified this run — honest status)

The file is doubly dead in DragonFly: it is absent from sys/dev/drm/amdgpu/Makefile SRCS (lines 195-201 list amdgpu_dm.c, amdgpu_dm_irq.c, amdgpu_dm_mst_types.c, amdgpu_dm_color.c, services, helpers, pp_smu — not this file), and its only two callers are compiled under #if defined(CONFIG_DEBUG_FS) (amdgpu_dm.c:478-479 dtn_debugfs_init, :4119-4120 connector_debugfs_init), which is not defined (sys/dev/drm/kconfig.h). So today this is an enable-day hazard (turning on debugfs builds without also fixing validation), consistent with DF-1764/DF-1765/DF-4554 precedent. The guest also has no AMD GPU (pciconf: no AMD devices).

What runs today

dp_link_logic_demo.c transcribes the validation logic (:195-221) and the consumer loop (:394-410) 1:1 and runs on the guest — gcc itself flags the OOB iteration (warning: iteration 4 invokes undefined behavior):

input: lane_count=5 (invalid), link_rate=0xa (valid)
ACCEPTED by the single valid_input flag (amdgpu_dm_debugfs.c:195-221)
stored preferred_link_setting.lane_count = 5 (dc.c:484, unvalidated)
loop iteration r=4: OOB write at &lane_settings[4] -- past lane_settings[LANE_COUNT_DP_MAX-1=3]

(demo_run.log; a transcription logic-proof, NOT a kernel run — see VERDICT.md)

Fix

fix.diff splits the flag into valid_lane_count / valid_link_rate and requires both (if (!valid_lane_count || !valid_link_rate)).

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.