DF-4577 — VERDICT (pass 2, df-bsd-reviewer)

Status: untested (kernel level) / analytically certain (arithmetic proof)
Impact: none on kernel memory safety; fail-closed loss of HDCP1.4 repeater
        authentication (content-protection feature cannot engage for
        topologies with >= 2 downstream devices).

## Root cause (path:line)

sys/dev/drm/i915/intel_hdcp.c:221-223 — the KSV fill loop parks each new
byte at slot `(sizeof(sha_text) - j - 1) * 8`, ignoring the
`sha_leftovers` bytes already parked in those top slots by
intel_hdcp.c:237-239 during the previous iteration. From the second KSV on,
`ksv[0]` OR-collides with the parked leftover byte and every following byte
lands one slot too high (zero in the LSB slot). The HDCP_SHA_TEXT byte
stream therefore diverges from the required KSV concatenation at stream
byte 5 for any topology with >= 2 downstream devices.

Upstream comparison (fetched from torvalds/linux during this audit):
  v4.17, v4.18, v5.4, v5.15-era: identical buggy form
  v5.17+ (HDCP rework, drivers/gpu/drm/i915/display/intel_hdcp.c:527-529):
     `u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) * 8);`  — FIXED
DF's tree carries the pre-fix form.

## Why fail-closed

The corrupted stream is hashed by the display engine and compared against
the sink-supplied V' (intel_hdcp.c:383-392). A wrong hash can only produce
a mismatch (HDCP_SHA1_V_MATCH clear) -> -ENXIO, never a false pass:
  intel_hdcp_validate_v_prime (-ENXIO x3)
   -> intel_hdcp_auth_downstream err          (intel_hdcp.c:452-455)
   -> _intel_hdcp_enable fails all 3 tries    (intel_hdcp.c:679-692)
   -> intel_hdcp_enable returns error, property stays DESIRED
No bypass, no escalation, no memory unsafety. Security consequence is the
unavailability of the content-protection mechanism on repeater topologies.

## Evidence

- findings/poc/DF-4577/df4577_sim.c — faithful simulation of both forms
- findings/poc/DF-4577/run.log — output compiled+run on the audit guest
  (DragonFly 6.5-DEVELOPMENT x86_64, gcc): DF form diverges at byte 5
  (`5|6 = 7`) for N>=2; upstream form emits the exact concatenation 1..20
  for N=5; N=1 correct in both (leftover consumed by the BSTATUS tail).
- Upstream fix reference: torvalds/linux v5.17+
  drivers/gpu/drm/i915/display/intel_hdcp.c:529.

## Verification status

Kernel-level reproduction is hardware-gated (needs Intel HSW/gen8+ display,
an HDCP repeater sink with >=2 downstream devices, an enabled CRTC, and a
DRM_MASTER fd in group video — DRM_IOCTL_MODE_OBJ_SETPROPERTY is
DRM_MASTER-gated at sys/dev/drm/drm_ioctl.c:679; /dev/dri/card* is
root:video 0660 per etc/defaults/devfs.conf:7). The QEMU audit guest has
no i915-class GPU, so status is "untested" for the kernel path. The
arithmetic proof is conclusive for the root cause, and fix.diff is exactly
the upstream v5.17 correction (validated by the same simulation).

## Negative results recorded during this pass (context)

- Repeater KSV FIFO sizing: HDMI shim reads exactly N*5 bytes
  (intel_hdmi.c:1048-1059), DP shim 15-byte windows bounded by min()
  (intel_dp.c:5482-5493); num_downstream masked to 7 bits
  (drm_hdcp.h:22) -> kcalloc(5, <=127) with exact fill — the "classic"
  overflow does NOT exist here.
- intel_hdcp_atomic_check NULL-crtc-state: killed — drm_atomic_get_connector_state
  allocates the CRTC state (drm_atomic.c, tail of function) whenever the
  connector keeps its CRTC, so intel_hdcp.c:824 cannot deref NULL.
- Work lifetime: hdcp_check_work/hdcp_prop_work cancelled before connector
  destruction at unload (intel_display.c:16175-16177, before
  drm_mode_config_cleanup).
- bksv/an/ri/vprime unions fully initialized before shim reads
  (intel_hdcp.c:508-528, 584).

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