DF-4453 — RVDA VBT mapping: pmap_mapbios() of firmware-supplied 64-bit address / 32-bit length with no validation (i915 OpRegion)

File: sys/dev/drm/i915/intel_opregion.c (pass 2)

Root cause

intel_opregion_setup() maps the raw VBT pointer taken verbatim from the firmware-shared ASLE mailbox:

if (opregion->header->opregion_ver >= 2 && opregion->asle &&
    opregion->asle->rvda && opregion->asle->rvds) {
        opregion->rvda = pmap_mapbios(opregion->asle->rvda,      /* u64 phys addr :126 */
                                      opregion->asle->rvds);     /* u32 size     :127 */
        vbt = opregion->rvda;
        vbt_size = opregion->asle->rvds;
        if (intel_bios_is_valid_vbt(vbt, vbt_size)) {

(sys/dev/drm/i915/intel_opregion.c:1029-1043)

• No check that rvda/rvds describe sane memory, no rvda+rvds overflow check, no upper bound on rvds (up to 4 GiB-1). DragonFly's pmap_mapbios() (sys/platform/pc64/x86_64/pmap.c:6180) maps any physical address with any length into KVA, write-back cached, and only fails by panic("pmap_mapdev: Couldn't alloc kernel virtual memory") (pmap.c:6208) — i.e. a large enough rvds request that exhausts the kernel_map KVA arena becomes a kernel panic, not an error return.
• The OpRegion contents (rvda/rvds) are SMM/firmware-writable shared memory.
• The mapping is re-established on every resume (intel_opregion_setup() called from i915_drm_resume(), sys/dev/drm/i915/i915_drv.c:2124) while iounmap() never releases pmap_mapbios KVA (the DF-1629 mechanism), so each suspend/resume cycle leaks up to rvds bytes of KVA + page-table entries: an unbounded amplification of DF-1629 by firmware-chosen size.
• Downstream is safe: a failed map (rvda == NULL) is rejected by intel_bios_is_valid_vbt()'s NULL check (sys/dev/drm/i915/intel_bios.c:1655), and the VBT block walks live in intel_bios.c, not in this file.

Impact

Firmware-trust boundary issue (malicious/compromised VBIOS-SMM or a re-flashed OpRegion): kernel KVA/PTE exhaustion (system-wide resource starvation, KVA arena fragmentation), and in the pmap_mapdev OOM case a direct kernel panic at boot. Not reachable from an unprivileged local user; no guest runtime test possible (the audit QEMU guest has no Intel GPU — i915 never attaches).

Fix direction (see fix.diff)

Validate before mapping:

if (opregion->header->opregion_ver >= 2 && opregion->asle &&
    opregion->asle->rvds >= sizeof(struct vbt_header) &&
    opregion->asle->rvds <= VBT_MAP_MAX &&              /* e.g. 4 MiB */
    opregion->asle->rvda &&
    opregion->asle->rvda + opregion->asle->rvds > opregion->asle->rvda) {

and bail to the mailbox-#4 VBT on validation failure (upstream Linux took the same approach of bounding the rvda mapping, commit 6b4e4ba2cc02 family).