DF-4814 — parse_csr_fw walks package_header->fw_info[20] with unbounded attacker num_entries: kernel heap OOB read (-> panic / OOB dmc_offset).

BUILD/RUN (guest-compiled logic harness; kernel path itself needs gen9+ HW):

# on the audit guest (or any POSIX box):
cc -O2 -o poc4814 poc4814.c
./poc4814          # variant A: minimal 1536-byte crafted DMC file
./poc4814 big      # variant B: 1 MiB crafted DMC file

EXPECTED (observed, see run.log): SIGSEGV while reading fw_info[115] (A) / fw_info[87369] (B) — i.e. far past the 20-entry fw_info array, and past the END of the firmware buffer, with the loop still bounded only by the crafted num_entries=0x08000000 (1.5 GiB of address space walked). The harness traps the fault and prints the diagnosis; in-kernel the same walk is a page fault in kernel mode (panic) or an OOB-read dmc_offset feeding &fw->data[readcount+dmc_offset*4].

STATUS: status=untested for the kernel path (no gen9+ Intel display device exists in the audit guest — see env.txt); the parse-loop logic itself is demonstrated by the harness (run.log). Fix validated statically (see VERDICT.md / fix.diff, mirrors upstream v5.10 num_entries sanitization).

DF-4814 VERDICT — intel_csr.c unbounded num_entries walk (OOB heap read)

Bottom line: parse_csr_fw() bounds its stepping-search loop with the attacker-controlled package_header->num_entries (u32 from the DMC firmware file) while the walked array is the fixed struct intel_fw_info fw_info[20] declared inside struct intel_package_header. There is no check of num_entries against ARRAY_SIZE(fw_info) — for num_entries > 20 the loop reads kernel heap beyond the array; for large counts it walks off the end of the request_firmware() buffer entirely. Kernel-mode OOB read → page fault panic (reliable DoS), and whatever u32 it reads OOB becomes dmc_offset, which is then used to index fw->data again (compounding DF-1895's unchecked indexing). Root cause is distinct from DF-1895: even a fully fw->size-checked parse (the DF-1895 fix) leaves this bug — the missing bound is the array size (20), not the file size; variant B of the harness proves a 1 MiB file (far larger than needed) still gets walked off its end.

The defect (path:line, this tree)

• sys/dev/drm/i915/intel_csr.c:134-136 — num_entries u32 + fw_info[20] inside struct intel_package_header (__packed, total 256 bytes).
• sys/dev/drm/i915/intel_csr.c:353-365 — the loop: for (i = 0; i < package_header->num_entries; i++) reading package_header->fw_info[i].substepping/.stepping/.offset with no ARRAY_SIZE(package_header->fw_info) bound. (Note the '*'/'*' wildcard arm at :362-364 deliberately does NOT break, so the walk continues.)
• sys/dev/drm/i915/intel_csr.c:372-376 — OOB-read offset becomes dmc_offset *= 4; readcount += dmc_offset; dmc_header = &fw->data[readcount].

Trust model / threat

The DMC firmware file is root-placed (loader path /modules/firmware/... via firmware_get(), or i915_modparams.dmc_firmware_path module param). The attacker is therefore "root writes a malicious firmware file" / "compromised firmware distribution" — the same trust model under which DF-1894 (High) and DF-1895 (Medium) were filed for this file. The load itself is asynchronous (schedule_work at intel_csr.c:507) from driver load on gen9+ hardware; any user who can (re)boot/reload the driver triggers the parse. Severity kept at Medium to stay consistent with DF-1895's calibration.

Verification performed (honest classification)

• Guest kernel runtime: NOT possible. The audit guest's only display device is QEMU std-VGA 0x1234:1111 (see env.txt). parse_csr_fw is reachable only when HAS_CSR() (gen9+ Intel display) — no such hardware exists in the guest, so the kernel path cannot execute there. Status: untested per the allowed enum (device absent, not a failed attempt).
• Logic replication: REPRODUCED on the audit guest itself. poc_csr_num_entries.c copies the packed struct definitions (intel_csr.c:111-137) and the exact loop (intel_csr.c:353-365) verbatim, places the crafted firmware flush against a PROT_NONE guard page (modeling the end of the kernel heap allocation), and runs it:
  • variant A (1536-byte file, minimal structurally-valid headers): fault reading fw_info[115] — the array holds 20 entries; the walk left the file 3 bytes earlier and kept going (run.log).
  • variant B (1 MiB file): fault reading fw_info[87369] — proves that no plausible file size bounds the walk; the loop bound alone is num_entries, here 0x08000000 (1.5 GiB of walk). Compiled and executed on the DragonFly guest (cc -O2, DF 6.5-DEVELOPMENT). In the kernel the identical walk reads past the firmware_get() buffer until an unmapped page → kernel-mode page fault → panic; short of that it harvests heap bytes into dmc_offset.
• Upstream provenance (verified against tags, saved under evidence/): upstream v5.2 has the same unbounded loop; upstream v5.10 added the sanitization — parse_csr_fw_package(): num_entries = package_header->num_entries; if (WARN_ON(package_header->num_entries > max_entries)) return 0; and the walker comment "num_entries is already sanitized". So this is an upstream-inherited bug that upstream later fixed; the DF tree never received that fix.

Why this is NOT a re-report of DF-1895

DF-1895 = "never validates fw->datasize before indexing fw->data" — the fix is bounds-checking every &fw->data[...] access against fw->size. That fix does not touch the fw_info[i] loop bound: a 1 MiB file with num_entries=0x20000 passes every conceivable fw->size check at the package-header stage yet still reads fw_info[i] for i≥21 (intra-file OOB w.r.t. the struct array) and, for larger counts, past the file end (harness variant B). Complementary, independent missing check.

Exploit chain (ceiling)

Root-supplied DMC file → async work csr_load_work_fn → parse_csr_fw → unbounded heap walk → (a) kernel panic (deterministic with unmapped-page landing) = local DoS at driver load; (b) controlled-ish OOB read: heap bytes at fw_info[21..] feed dmc_offset (and via '*'-wildcard entries, the last matching OOB entry wins), steering further reads at &fw->data[384+dmc_offset*4] — with DF-1895 also unfixed this gives a heap read primitive whose contents land in dmc_payload and are then written to CSR_PROGRAM(i) MMIO (not readable back by userspace; so leak ceiling is low — DoS is the realistic impact). No path to uid=0: reads only, no writes past the dmc_payload allocation.

Fix

Bound the loop (mirrors upstream v5.10 sanitization):

--- a/sys/dev/drm/i915/intel_csr.c
+++ b/sys/dev/drm/i915/intel_csr.c
@@ -348,6 +348,13 @@ static uint32_t *parse_csr_fw(struct drm_i915_private *dev_priv,
        return NULL;
    }

+   if (package_header->num_entries > ARRAY_SIZE(package_header->fw_info)) {
+       DRM_ERROR("DMC firmware has wrong package num_entries %u\n",
+             package_header->num_entries);
+       return NULL;
+   }
+
    readcount += sizeof(struct intel_package_header);

(see fix.diff — authored against the read-only sys/ tree, never applied)

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.