# DF-4731 VERDICT

## Status: `untested` (kernel path hardware-gated) — guard defect proven by guest-executed logic proof

## What was verified

1. **The code defect is certain (static, line-cited).**
   - `sys/dev/drm/amd/display/dc/irq_types.h:147` — last enum member
     `DAL_IRQ_SOURCES_NUMBER = 90` (counted: INVALID=0 … DC6_VLINE0=89, NUMBER=90).
   - `sys/dev/drm/amd/display/dc/irq_types.h:157-158` —
     `#define DAL_VALID_IRQ_SRC_NUM(src) ((src) <= DAL_IRQ_SOURCES_NUMBER && (src) > DC_IRQ_SOURCE_INVALID)`
     accepts `src == 90`.
   - Arrays: `sys/dev/drm/amd/display/amdgpu_dm/amdgpu_dm.h:106-107` —
     `struct irq_list_head irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];`
     `struct list_head   irq_handler_list_high_tab[DAL_IRQ_SOURCES_NUMBER];`
     → valid indices 0..89.
   - Consumers in the audited file:
     `amdgpu_dm_irq.c:176` (`validate_irq_registration_params`) → `:238`/`:242`
     (`hnd_list = &adev->dm.irq_handler_list_{high,low}_tab[irq_source]`, then
     `list_add_tail` at `:246`);
     `amdgpu_dm_irq.c:193` (`validate_irq_unregistration_params`) → `:123`/`:127`
     (list walk + `list_del` + `kfree` in `remove_irq_handler`).
   - DC side is correctly bounded elsewhere: `irq_service.c:82`
     (`find_irq_source_info` uses `>=`), which shows `<=` is the outlier.

2. **Proof-of-logic executed on the DragonFly guest** (run.log): with the tree's
   verbatim enum and macro, `DAL_VALID_IRQ_SRC_NUM(90)` == true, (89) == true,
   (91) == false — an exact off-by-one acceptance window of exactly one
   out-of-bounds index.

3. **Upstream comparison**: Linux v4.17 `drivers/gpu/drm/amd/display/dc/irq_types.h`
   contains the identical `<=` macro (fetched and diffed during this audit) —
   the defect is inherited, not a DragonFly port typo.

## Why the kernel path was not exercised

The QEMU guest has no AMD display hardware (`/dev/dri` absent; only
`vgapci0: <VGA-compatible display> chip=0x11111234` QEMU virtual VGA; no drm
kld loaded — env.txt). `amdgpu_dm_irq_register_interrupt()` is only reachable
behind a functioning amdgpu DC, so triggering the in-kernel OOB `list_add_tail`
is impossible on this guest.

## Reachability on real hardware (why Low, not higher)

Every caller of `amdgpu_dm_irq_register_interrupt()` on this tree passes an
in-range source:
- `amdgpu_dm.c:1274-1292` (`register_hpd_handlers`): `dc_link->irq_source_hpd{,_rx}`,
  both guarded by `!= DC_IRQ_SOURCE_INVALID`.
- `amdgpu_dm.c:1334-1345, 1356-1366` (dce110) and `:1419-1452` (dcn10):
  `dc_interrupt_to_irq_source(dc, i, 0)` — every `to_dal_irq_source_*`
  implementation returns either a valid enum constant or `DC_IRQ_SOURCE_INVALID`
  (= 0, in-bounds) (`irq_service_dce110.c:315-391`).
`amdgpu_dm_irq_unregister_interrupt()` has **zero callers** tree-wide.
So no user-, hardware-, or packet-derived value currently reaches the guard
with 90 — the finding is a latent guard defect / hardening item, exactly the
kind of bound every future caller will trust.

## Fix validation

Not testable (needs AMD GPU to build a baseline kernel scenario). `fix.diff`
(`<=` → `<`) is the minimal correct change; it cannot regress the valid range
(89 still accepted, 0 still rejected — verified by the same harness logic).

## Bottom line

Real one-past-end guard bug in the validation macro the audited file trusts for
every handler-list index; inherited verbatim from Linux 4.17; latent (no live
caller can pass the OOB value today); fixed by one character.

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