DF-4663 — dc_link_ddc: unchecked payloads_create() NULL in dal_ddc_service_query_ddc_data

dal_ddc_service_query_ddc_data() (dc_link_ddc.c:552-633) calls dal_ddc_aux_payloads_create(ddc->ctx, payloads_num) (:580-581) or dal_ddc_i2c_payloads_create(...) (:606-607) and immediately dereferences the result via dal_ddc_aux_payloads_get(payloads) (:584) / dal_ddc_i2c_payloads_get(payloads) (:610) — reading payloads->payloads.container (offset 0, include/vector.h:29-35) — with no NULL check.

Both creators return NULL when: * the 16-byte kzalloc fails (GFP_KERNEL, OOM), or * dal_vector_construct() rejects capacity == 0 (basics/vector.c:33-37) — i.e. whenever write_size == 0 && read_size == 0 — or its kcalloc fails.

The zero-size case is not reachable from the current in-tree callers (all pass non-empty write or read sizes: dc_link_ddc.c:712-754 SCDC, dc_link.c:1641/1694 retimer (1,1)), so today this is an OOM-gated latent NULL-deref panic inside the amdgpu display driver. Filed as hardening (defense-in-depth; the sibling engine paths DF-4555-series showed this subsystem's allocation/error discipline is security-relevant).

Run / verification

Hardware-gated: the code only executes on an AMD DC GPU. The audit guest has none — pciconf -l | grep -c 1002 = 0 (run.log / env.txt), Bochs VGA only. Not reproducible there; defect is code-provable (cited lines).

Fix

fix.diff (git-apply verified): check both create results, return false on failure — consistent with the file's own bound check at :573-574.

DF-4663 — VERDICT

not_reproduced (hardware-gated) — Info-severity hardening finding; defect code-provable.

Root cause (certain, from source)

dal_ddc_service_query_ddc_data (sys/dev/drm/amd/display/dc/core/dc_link_ddc.c:552):

580:  struct aux_payloads *payloads =
581:      dal_ddc_aux_payloads_create(ddc->ctx, payloads_num);
...
584:  .payloads = dal_ddc_aux_payloads_get(payloads),   /* NULL->payloads.container */

and the i2c twin at :606-610. dal_ddc_aux_payloads_create (:170-185) returns NULL when kzalloc(sizeof(struct aux_payloads)) fails or when dal_vector_construct fails — which it deterministically does for capacity == 0 (if (!struct_size || !capacity) ... return false, basics/vector.c:33-37, i.e. write_size == 0 && read_size == 0) and when its kcalloc fails. dal_ddc_aux_payloads_get(NULL) then reads NULL->payloads.container (container is the first member of struct vector, include/vector.h:29-35) → near-NULL read → panic.

Why not reproduced

The function only executes on amdgpu display hardware (driver core path). The audit guest: pciconf -l | grep -c 1002 → 0 (no AMD device; Bochs 0x1234:0x1111 VGA) — run.log. Same gating as DF-4555/DF-4556.

Reachability analysis

• OOM path: any amdgpu DC system under extreme memory pressure during a DDC transaction (EDID read / SCDC write / retimer query) → NULL deref panic. Requires GFP_KERNEL failure of a 16-byte alloc — rare but real.
• Zero-size path: payloads_num == 0 requires write_size==0 AND read_size==0. All current callers pass non-zero sizes (SCDC paths :712-754; retimer dc_link.c:1641/:1694 pass (1,1)) → not reachable in-tree today; any future caller with both sizes zero panics deterministically. This makes the missing check a latent trap, hence Info severity.

Fix

fix.diff adds if (!payloads) return false; after both creators (git-apply --check verified against the pristine tree; never applied to sys/). No fix validation run: the defective path requires absent hardware, and the patch is a two-line guard whose semantics are total. fix_status: fixed (author-verified apply + logic), fix runs not testable on this guest → fix_baseline_reproduced=0, fix_patched_reproduced=0.

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.