DF-4205 — vlv_dsi_init dereferences vbt.dsi.config without NULL/dangling guard

File: sys/dev/drm/i915/vlv_dsi.c (pass 2) Severity: Low | Confidence: certain | CWE-476 (NULL pointer dereference) / CWE-457 (use of uninitialized/freed pointer variant)

Build / Run

No build or run: Phase V skipped per contract (Low severity, firmware-gated trigger). The audit QEMU guest has no Intel GPU, so i915 never attaches and vlv_dsi_init is not reachable there; the trigger additionally requires a VBT whose child-device list declares a MIPI output while the BDB_MIPI_CONFIG block is absent (or an OOM at a specific kmemdup).

Static repro of the path is fully cited below — the defect is provable from source alone.

Expected behavior if triggered (on real VLV/CHV/BXT hardware)

• Missing BDB_MIPI_CONFIG + MIPI child device present: kernel NULL-page deref panic at driver attach (config->dual_link, vlv_dsi.c:1797).
• OOM in the pps kmemdup after config kmemdup succeeded: 1-byte UAF read at vlv_dsi.c:1797, then full parse of freed memory in intel_dsi_vbt_init (intel_dsi_vbt.c:523-544) and ->pwm_blc read at vlv_dsi.c:1826.

The path (path:line)

1. vlv_dsi_init() vlv_dsi.c:1747 — intel_bios_is_dsi_present(dev_priv, &port) returns true based on the child device list (intel_bios.c:2034-2047: any child with DEVICE_TYPE_MIPI_OUTPUT and dvo_port in {DVO_PORT_MIPIA, DVO_PORT_MIPIC}).
2. dev_priv->vbt.dsi.config is populated by a different BDB section: parse_mipi_config() intel_bios.c:826-830 — if find_section(bdb, BDB_MIPI_CONFIG) fails it returns with dsi.config == NULL.
3. intel_bios.c:843-851 — dsi.config = kmemdup(...); on pps kmemdup failure (line 848-851) it does kfree(dev_priv->vbt.dsi.config) without setting it to NULL → dangling.
4. Back in vlv_dsi_init: vlv_dsi.c:1797 dev_priv->vbt.dsi.config->dual_link and vlv_dsi.c:1826 dev_priv->vbt.dsi.config->pwm_blc — dereferenced with no guard.

Nothing between intel_bios_init and vlv_dsi_init re-checks dsi.config or dsi.panel_id (which stays MIPI_DSI_UNDEFINED_PANEL_ID when the section is missing — intel_bios.c:816,855).

Distinct from known findings

• DF-1390: OOB indexing inside parse_mipi_config (config[panel_type]).
• DF-1773: NULL-deref of vbt.lfp_lvds_vbt_mode in intel_dsi_vbt_init (different pointer, later in the call chain — it never runs because vlv_dsi.c:1797 faults first).
• DF-4122: block-size floors in other parse_* consumers.

Fix

Guard at the consumer (this file) + NULL the dangling pointer at the producer — see fix.diff.

Threat model / impact ceiling

Attacker needs to control the Intel VBT (BIOS/OpROM flash = root) or hit a narrow OOM. Impact: kernel panic at driver attach (local DoS of the boot / driver load), not arbitrary code execution. Rooted-firmware supply chain or broken BIOS is the realistic scenario.

DF-4205 VERDICT

Status: untested (Phase V skipped — Low severity, firmware/OOM-gated, no Intel GPU on the audit guest). Bug existence: certain, proven from source.

Root cause

vlv_dsi_init() decides DSI is present from the VBT child device list (intel_bios_is_dsi_present, intel_bios.c:2034-2047), but then dereferences dev_priv->vbt.dsi.config (vlv_dsi.c:1797 ->dual_link, :1826 ->pwm_blc) which is only populated when a different BDB section (BDB_MIPI_CONFIG) exists AND both kmemdups succeed (intel_bios.c:826-856). The two presence signals are decoupled; there is no guard at the consumer.

Three concrete failure inputs:

1. NULL deref (panic) — VBT has a MIPI child device but no BDB_MIPI_CONFIG section: find_section() returns NULL (intel_bios.c:826-830), dsi.config stays NULL, vlv_dsi_init runs to :1797 and faults on the NULL page. Kernel panic at i915 attach.
2. NULL deref (OOM) — kmemdup(config) fails (intel_bios.c:843-845): config stays NULL, same fault at :1797.
3. UAF read — kmemdup(pps) fails after config succeeded (intel_bios.c:847-851): kfree(dsi.config) leaves the pointer dangling; vlv_dsi.c:1797 reads dual_link from freed memory (1 byte), then intel_dsi_vbt_init() parses the entire freed struct mipi_config (intel_dsi_vbt.c:506,523-544) and vlv_dsi.c:1826 reads pwm_blc.

Why not verified on the guest

• The audit QEMU guest exposes no Intel GPU; i915 does not attach, so vlv_dsi_init is unreachable by construction (not_testable conditions).
• Even on hardware, the trigger is firmware content (VBT) or a specific OOM, neither of which an unprivileged guest user controls.
• Severity Low → contract exempts from Phase V.

Impact ceiling

Boot/attach-time kernel panic (DoS) in case 1-2; a UAF read of a 484-byte driver-allocated struct in case 3 (no attacker-controlled content is written through it before free — values are copied into intel_dsi fields and programmed to display registers; worst case is garbage register programming after the freed block is reallocated, still no write primitive from userland). No privilege escalation path: the trigger is not user-reachable.

Fix

fix.diff: (a) bail to the (correct, pre-connector) err label when vbt.dsi.config is NULL in vlv_dsi_init; (b) NULL the pointer after the pps-failure kfree in intel_bios.c so no dangling pointer survives. Both hunks are required; neither alone closes case 3.

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.