DF-3599 — cz_init_cp_jump_table NULL dereference when Carrizo MEC2 firmware is absent

What

gfx_v8_0_init_microcode() treats a failed MEC2 firmware request as non-fatal on every non-Topaz/non-Stoney asic:

    gfx_v8_0.c:1156-1173
    err = request_firmware(&adev->gfx.mec2_fw, fw_name, adev->dev);
    ...
    } else {
        err = 0;
        adev->gfx.mec2_fw = NULL;      /* :1172 — load continues OK */
    }

but on Carrizo the RLC init path unconditionally walks a 5th jump-table slot that dereferences that pointer:

    gfx_v8_0.c:1309-1310
    if (adev->asic_type == CHIP_CARRIZO)
        max_me = 5;
    ...
    gfx_v8_0.c:1347-1349
    } else if (me == 4) {
        const struct gfx_firmware_header_v1_0 *hdr =
            (const struct gfx_firmware_header_v1_0 *)adev->gfx.mec2_fw->data;  /* NULL->data */

struct firmware.data sits at a small offset, so with mec2_fw == NULL this reads from the unmapped NULL page and the subsequent le32_to_cpu(hdr->header.ucode_array_offset_bytes) at :1352 and the copy loop at :1357-1359 fault — kernel panic during gfx_v8_0_rlc_init() (:1418, reached from gfx_v8_0_sw_init :2091) → driver probe failure / boot-time panic on a CZ system whose amdgpufw_carrizo_mec2 module is missing or unreadable.

Stoney is unaffected (its max_me stays 4 and it never loads mec2 anyway).

Threat model / severity

Requires the MEC2 firmware file to be absent or unrequestable on a Carrizo machine: broken install, root-deleted/replaced firmware module, or distro image gap. Availability-only (NULL-page read → panic), privileged precondition → Low.

Reproduce

Not executable on the audit guest (virtio-only, no AMD GPU, no amdgpu module). Source assertion:

./run.sh

prints the NULL-assigning fallback, the CZ-only max_me = 5, and the unguarded mec2_fw->data dereference on the me == 4 branch.

Fix

fix.diff: only take the 5th slot when adev->gfx.mec2_fw != NULL.

DF-3599 — VERDICT

status: inconclusive (kernel run) / source certain reproduced: 0

Proof

1. gfx_v8_0_init_microcode :1156-1173 — on MEC2 request_firmware failure the else branch resets err = 0 and sets adev->gfx.mec2_fw = NULL; initialization therefore succeeds with a NULL MEC2 pointer (this fallback is intentional for asics where mec2 is optional — but Carrizo's RLC init is not optional).
2. cz_init_cp_jump_table :1309-1310 — if (adev->asic_type == CHIP_CARRIZO) max_me = 5;
3. :1347-1352 — the me == 4 iteration computes (const struct gfx_firmware_header_v1_0 *)adev->gfx.mec2_fw->data and then le32_to_cpu(hdr->header.ucode_array_offset_bytes) at :1352, hdr->jt_offset/hdr->jt_size at :1321-1322 pattern → with mec2_fw == NULL these read from the NULL page (offset of data within struct firmware is small) → page fault → kernel panic during gfx_v8_0_rlc_init :1418 → gfx_v8_0_sw_init :2091 returns after the probe has already emitted no error for the missing fw.
4. Reachability precondition: Carrizo system + missing/unreadable amdgpufw_carrizo_mec2 firmware module (broken install, deleted or replaced module). Availability-only; privileged control of firmware files → severity Low.

Stoney never reaches me == 4 (max_me stays 4, and Stoney never loads mec2 — :1147-1148), so only Carrizo is affected.

Why not a kernel run

Audit guest is virtio-only — no AMD PCI device, no drm/amdgpu module, no /boot/modules. The dereference path requires a Carrizo APU to probe. inconclusive at runtime; the NULL-deref control flow is unambiguous from source (see run.log excerpts).

Fix validation

fix.diff gates the 5th slot on adev->gfx.mec2_fw != NULL. Kernel build/run not possible on this guest — fix_status: not_testable; diff line-matched to gfx_v8_0.c:1309-1310.

kernel_refs

• sys/dev/drm/amd/amdgpu/gfx_v8_0.c:1170-1173 (NULL fallback)
• sys/dev/drm/amd/amdgpu/gfx_v8_0.c:1309-1310 (CZ max_me=5)
• sys/dev/drm/amd/amdgpu/gfx_v8_0.c:1347-1355 (unguarded deref)
• sys/dev/drm/amd/amdgpu/gfx_v8_0.c:1405-1418 (caller path)
• sys/dev/drm/amd/amdgpu/gfx_v8_0.c:2091 (sw_init entry)

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.