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

```c
	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:

```c
	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`.