• File: sys/dev/drm/i915/intel_fbc.c
• Lines: 559, 561, 494, 524, 543
• Severity: High
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:H/I:H/A:H
• CWE: CWE-416 Use After Free
• Confidence: certain

Summary

__intel_fbc_cleanup_cfb() calls kfree(fbc->compressed_llb) without NULLing the pointer, and __intel_fbc_cleanup_cfb is invoked twice in normal lifecycles (once via intel_fbc_disable/intel_fbc_global_disable on CRTC teardown or suspend, and again unconditionally via intel_fbc_cleanup_cfb on driver unload at i915_drv.c:1862).

The second call sees the dangling pointer, passes it to i915_gem_stolen_remove_node() → drm_mm_remove_node(), which dereferences freed heap memory, performs rbtree/list mutations on it, and BUG_ONs on the allocated flag reinterpreted from whatever now occupies the slab slot.

Root cause

intel_fbc.c:559-562:

if (fbc->compressed_llb) {
    i915_gem_stolen_remove_node(dev_priv, fbc->compressed_llb);
    kfree(fbc->compressed_llb);
}

There is no fbc->compressed_llb = NULL; after the kfree.

Compare with the sibling compressed_fb node, which IS guarded by if (drm_mm_node_allocated(&fbc->compressed_fb)) (line 556) and drm_mm_remove_node() clears node->allocated=false (drm_mm.c:607), making the check idempotent.

The compressed_llb pointer has no such protection — it is a bare kzalloc'd struct drm_mm_node * (line 515) assigned to fbc->compressed_llb only on the success path (line 524), and is never reset.

After the first cleanup, fbc->compressed_llb is a dangling pointer to freed general-purpose slab memory.

Call graph proving the double-invocation:

• intel_fbc_enable → intel_fbc_alloc_cfb (success: fbc->compressed_llb = ptr) [line 1097]
• intel_fbc_disable → __intel_fbc_disable → __intel_fbc_cleanup_cfb (first free, ptr dangling) [line 1129 → 891]
• i915_drv.c:1862 intel_fbc_cleanup_cfb → __intel_fbc_cleanup_cfb unconditionally on unload (dangling deref) [line 573]
• or i915_suspend.c:50 intel_fbc_global_disable on suspend, then later unload → same UAF

err_fb in intel_fbc_alloc_cfb (line 543-545) only kfrees the LOCAL compressed_llb variable, never touching fbc->compressed_llb — so a failed re-alloc after a prior successful alloc also leaves fbc->compressed_llb dangling.

The UAF sink, drm_mm_remove_node (drm_mm.c:588), executes DRM_MM_BUG_ON(!node->allocated) (line 597), drm_mm_interval_tree_remove (line 605), and list_del (line 606) — all of which dereference and mutate fields inside the freed struct drm_mm_node.

If the slab has been reused (struct drm_mm_node is ~80 bytes, a popular kmalloc-128 slab), these operations corrupt the replacer's rbtree/list pointers, and the BUG_ON can fire if the reused memory reads allocated==0.

Threat

Local unprivileged attacker on a system with an affected Intel GPU (any i915 platform with FBC where INTEL_GEN < 5 and !IS_GM45 — i.e. i8xx, i915/i945, pineview, gen4 non-GM45; the else branch at intel_fbc.c:514).

The attacker needs only DRM master privileges (any X/Wayland client can become master on its own seat, or root via console) to trigger an FBC enable/disable cycle through normal mode-setting (intel_fbc_enable is called from intel_display.c:12630 in the atomic-commit path).

After the disable, suspending or unloading the driver — both routine and triggerable by an unprivileged user via lid close, sysfs /sys/power/state on many configurations, or simply by GPU reset/unbind — re-enters __intel_fbc_cleanup_cfb and dereferences freed memory.

Impact: kernel BUG_ON panic (reliable local DoS) and, with slab grooming of the kmalloc-128 freelist before the second cleanup runs, the list_del/rbtree operations on attacker-influenced bytes can be turned into controlled kernel memory corruption, enabling LPE to uid 0.

The bug is present in the only path that uses the i8xx LLB stolen-node allocation, but on affected hardware it triggers on every suspend cycle.

Exploit / PoC

Trigger (reliable local DoS / panic, no grooming needed):

1. Target: any DragonFlyBSD system with a pre-gen5 non-GM45 Intel GPU that supports FBC (i8xx, i915GM, i945GM, G33, Q33, Q35, PineView). i915.enable_fbc must be settable to 1 (default is platform-dependent; intel_sanitize_fbc_option allows it on HAS_FBC hardware).

2. Use DRM atomic commit to enable FBC on a tiled XRGB8888 framebuffer sized 1024x768 with stride 1024*4 — this sets crtc_state->enable_fbc via intel_fbc_choose_crtc.

3. Atomic disable of the CRTC → intel_fbc_disable → __intel_fbc_cleanup_cfb (fbc->compressed_llb freed but not NULLed).

4. Force second cleanup. The simplest reliable path is unbind/rebind of the i915 driver, which calls i915_pci_remove → ... → intel_fbc_cleanup_cfb (i915_drv.c:1862):

echo -n 0000:00:02.0 > /sys/bus/pci/drivers/i915/unbind

On the write of the unbind sysfs attribute the unload sequence runs; intel_fbc_cleanup_cfb re-enters __intel_fbc_cleanup_cfb, which calls i915_gem_stolen_remove_node on the dangling fbc->compressed_llb pointer. drm_mm_remove_node() then reads allocated from freed memory and BUG_ONs or corrupts the rbtree.

Success criterion: kernel panic with panic: drm_mm_remove_node / BUG_ON at drm_mm.c:597, or kernel: general protection fault in drm_mm_interval_tree_remove.

For LPE: pre-allocate many objects of the same slab (struct drm_mm_node falls in kmalloc-128), free one to position the dangling fbc->compressed_llb into a known slot, then spray with controlled data so that on the second cleanup the node_list/rbtree pointers point at attacker-chosen addresses.

Recommended fix

Clear fbc->compressed_llb = NULL immediately after kfree in __intel_fbc_cleanup_cfb.

--- a/sys/dev/drm/i915/intel_fbc.c
+++ b/sys/dev/drm/i915/intel_fbc.c
@@ -556,8 +557,11 @@
    struct intel_fbc *fbc = &dev_priv->fbc;

    if (drm_mm_node_allocated(&fbc->compressed_fb))
        i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_fb);
-
    if (fbc->compressed_llb) {
        i915_gem_stolen_remove_node(dev_priv, fbc->compressed_llb);
        kfree(fbc->compressed_llb);
+       fbc->compressed_llb = NULL;
    }
 }

The minimal, sufficient fix is the single line fbc->compressed_llb = NULL; after kfree at intel_fbc.c:561.

This makes cleanup idempotent, mirroring the drm_mm_node_allocated protection already used for compressed_fb.