DF-5778 VERDICT — full narrative

File: sys/dev/drm/amd/display/dc/irq/irq_service.c (169 LOC, pass 2 GLM 5.3) Finding: Unguarded service-object dereference in dal_irq_service_to_irq_source plus swallowed dal_irq_service_construct failure — latent NULL-deref hardening gap. Class: CWE-476 (NULL pointer dereference, latent/defense-in-depth). Severity: Info. Confidence: certain (guards certainly absent; reachability certainly nil via in-tree callers — both proven below).

1. The defect (what is missing, exactly)

1. irq_service.c:160-169 — dal_irq_service_to_irq_source() executes

c return irq_service->funcs->to_dal_irq_source(irq_service, src_id, ext_id);

with no check of irq_service, irq_service->funcs, or the to_dal_irq_source member. Contrast the sibling entry points in the same file, which do validate before dereferencing: - dal_irq_service_set() (:101-114) and dal_irq_service_ack() (:138-150) validate via find_irq_source_info() (:77-86). - dal_irq_service_construct() (:53-63) validates init_data/ctx. - dal_irq_service_destroy() (:65-75) validates the handle. Even the DC wrappers are asymmetric: dc_interrupt_set() (core/dc.c:1681-1688) checks dc == NULL, while dc_interrupt_to_irq_source() (core/dc.c:1673-1679) and dc_interrupt_ack() (core/dc.c:1690-1693) check nothing.

2. irq_service.c:53-63 — dal_irq_service_construct() returns void. On bad init_data/ctx it bails (BREAK_TO_DEBUGGER(); return;) leaving the object zeroed. Every family constructor swallows that — e.g. dce110's construct() (irq_service_dce110.c:398-405) ignores the outcome, unconditionally wires info/funcs, and dal_irq_service_dce110_create() (:407-418) hands the object back as live. A ctx == NULL service would later reach dm_read_reg(irq_service->ctx, addr) (dm_services.h:66-77), whose ctx->cgs_device deref faults. Same shape in dce80/dce120/dcn10.

2. Reachability trace — why this is latent, not live

• init_data.ctx = dc->ctx at all 8 create sites (dce100_resource.c:960, dce110_resource.c:1306, dce112_resource.c:1252, dce120_resource.c:1010, dce80_resource.c:967/1177/1383, dcn10_resource.c:1362).
• dc->ctx is kzalloc'd and checked before resource-pool creation (core/dc.c:602-607 succeeds or goto fail; pool created at :671-678 only afterwards) ⇒ ctx can never be NULL when the family constructors run ⇒ the construct-failure branch is dead in-tree.
• pool->base.irqs = dal_irq_service_*_create() is NULL-checked at all 8 sites (if (!pool->base.irqs) goto res_create_fail;/ irqs_create_fail/fail) ⇒ res_pool->irqs is non-NULL in any live dc, and irq_service->funcs is unconditionally wired by the family constructors ⇒ dal_irq_service_to_irq_source's chain is non-NULL on every reachable call.
• Callers of the wrappers: amdgpu_dm_irq_handler (amdgpu_dm_irq.c:472-487) with a valid adev->dm.dc; register_hpd_handlers loops (amdgpu_dm.c:1336/1358/1421/1444); dm_irq_state/amdgpu_dm_set_* (amdgpu_dm_irq.c:357-670) — all with constructed dcs.
• No userland input reaches these entry points with pointer-shaped data; the only externally-shaped inputs are src_id/ext_id (hardware IV ring) which flow through funcs->to_dal_irq_source, not into the pointer chain.

Conclusion: no in-tree caller can produce the faulting object today. The gap matters for robustness (future callers, partial-init refactors, driver-teardown windows) — hence Info, defense-in-depth.

3. Verification (what ran, on what)

Guest: DragonFly 6.5-DEVELOPMENT (X86_64_GENERIC, with-src snapshot), cc 8.3, no AMD GPU (vgapci 0x1234:0x1111 QEMU VGA; /dev/dri absent). Per the reservation note for this file, the evidence class is a production-code KLD harness with synthetic tables.

df5778_harness.c compiles the verbatim production code — the complete enum dc_irq_source + DAL_VALID_IRQ_SRC_NUM (irq_types.h:36-158), the four structs (irq_service.h:36-70), the interface prototypes (irq_service_interface.h:28-47), and the six dispatcher function bodies (irq_service.c:77-169, byte-identical; the dm_read_reg/dm_write_reg/DC_LOG_ERROR macro interposition mirrors how dm_services.h itself provides them as macros) — against a synthetic [DAL_IRQ_SOURCES_NUMBER] table with physically-adjacent guard canaries and a register recorder standing in for cgs MMIO.

Decisive run (run.log, module loaded/unloaded cleanly, guest healthy):

• T1 (the finding): a zero-initialised irq_service (the object the swallowed-construct path would leave) has svc->funcs (offset +16) == NULL; the replication of the exact irq_service.c:165 deref chain shows the verbatim line would fault, with no guard on the path. Fault-free probe — the guest is not panicked by design.
• B1 (bounds, pass-2 angle (a)): find_irq_source_info accepts exactly 0..89 (0 = INVALID dummy slot, by design) and rejects one-past-end 90, 91, 95, 255, 65535, 0x7FFFFFFF, 0xFFFFFFFF ((enum)-1); every accepted pointer lands in-table. Canaries intact (B2). The table walk is in-bounds — executable negative result.
• B3: DAL_VALID_IRQ_SRC_NUM(90) == true (the DF-4731 macro off-by-one, filed on amdgpu_dm_irq.c — not re-reported here) while find_irq_source_info(90) == NULL: this file's >= defuses the macro on the set/ack paths.
• B4 (divergence, pass-2 angle (c)): upstream Linux v4.17 find_irq_source_info used source > DAL_IRQ_SOURCES_NUMBER — which accepts 90 and returns &info[90], a one-past-end read of the [90] family tables. The DFly tree uses >= (irq_service.c:82): stricter and correct. Verified by fetching torvalds/linux v4.17 (drivers/gpu/drm/amd/display/dc/irq/irq_service.c) during this audit and by emulating the upstream predicate in the harness. Apart from this predicate (and the static qualifier on find_irq_source_info), the file is byte-identical to upstream v4.17 — no port-introduced defects.
• T2: verbatim dal_irq_service_to_irq_source happy path executes correctly through the synthetic funcs.
• T3: dummy-slot dispatch (the family dummy_irq_entry() wiring, funcs non-NULL with log-and-fail members) produces zero register traffic and clean false returns — behaviorally distinct from the zero-filled VLINE0 slots of the DF-2168/4932/4995/5054/5078 family (known; not re-reported).
• T4: generic RMW dispatch reads/writes exactly the in-table synthetic registers with correct masking, ack-before-set ordering as in production.

Status: untested in the poc_results sense used for structural findings (house precedent DF-4731): the in-kernel manifestation cannot be exercised on this guest (no AMD GPU, and no in-tree caller can produce the NULL object). The structure of the missing guard and the correctness of everything around it were executed and verified.

4. Fix

fix.diff (authored post-verification, not applied to the read-only sys/ tree): - dal_irq_service_to_irq_source: reject !irq_service, missing funcs, or missing member with DC_IRQ_SOURCE_INVALID (callers already handle INVALID — dummy slot). - dc_interrupt_to_irq_source/dc_interrupt_ack (core/dc.c): the same dc/res_pool->irqs guard dc_interrupt_set already has.

A deeper (optional) hardening would make dal_irq_service_construct return bool and have the four family create() functions return NULL on failure; not included to keep the diff minimal and reviewable.

5. Fix validation

fix_status: not_testable — the guards are pure hardening on paths that cannot be driven to NULL on this guest (no AMD GPU; in-tree callers proven non-NULL). The harness's T1 probe is the baseline demonstration of the unguarded chain; with the guard applied the same object would return DC_IRQ_SOURCE_INVALID by inspection (single early-return). No kernel rebuild is warranted for an Info hardening finding; the guard logic was desk-checked line-by-line against the cited call sites.

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.