DF-4631 — radeon MST destroy_connector violates drm_connector kref lifetime (UAF / double-free / write-what-where / heap disclosure / unbounded encoder leak)

Status

REPRODUCED (verbatim-rig evidence class, DF-4165/DF-4247 protocol). Every defect family claimed by the finding was demonstrated in byte-identical production lifecycle code (56 checker-proven verbatim blocks: the radeon callbacks, the drm core connector kref machinery, the ENTIRE DRM_IOCTL_MODE_GETCONNECTOR body, and the exact MST topology unplug chain that invokes the buggy callback), compiled on the DragonFly guest against /usr/src — the tree its running kernel (Jul 2 2026 build) was compiled from — and driven through the kref sequences a real MST hub unplug/replug generates. The pack's fix.diff (replace the raw drm_connector_cleanup() + kfree() with drm_connector_put()) was A/B-validated in the same rig: baseline faults / double-frees / leaks on 5 of 9 modes; fixed build is clean 9/9. In-kernel execution remains radeon-ASIC + DP-MST-hub gated on this guest (Bochs VGA, no /dev/dri, no drm klds — proven in env.txt).

What was verified and how

The rig (rig/) sed-extracts the production lifecycle from the kernel tree:

• radeon driver (radeon_dp_mst.c): radeon_dp_add_mst_connector, radeon_dp_register_mst_connector, radeon_dp_destroy_mst_connector (the buggy raw free), radeon_dp_mst_connector_destroy (funcs->destroy), fake-encoder create/destroy, mst_cbs, mode helpers.
• drm core (drm_connector.c / drm_mode_object.c / drm_encoder.c): drm_connector_init/register/unregister/cleanup/free (the kref release handler), __drm_mode_object_add/register/unregister/find, drm_mode_object_get/put, the whole drm_mode_getconnector ioctl body (the racing reader: drm_connector_lookup kref at :1734 → ... → drm_connector_put at :1827), encoder init/cleanup.
• MST topology (drm_dp_mst_topology.c): drm_dp_add_mst_branch_device, drm_dp_free/destroy_mst_branch_device, drm_dp_put_mst_branch_device, drm_dp_port_teardown_pdt, drm_dp_destroy_port (queues the worker), drm_dp_free_mst_port + drm_dp_destroy_connector_work — the exact chain set_mst(false) drives at hub unplug.
• counting semantics verbatim: the tree's own kref.h + refcount.h inline bodies (plain atomic_dec_and_test, no underflow protection).

rig/check_verbatim.sh re-proves all 56 blocks byte-identical on the guest against /usr/src/sys (build.log: ALL VERBATIM CHECKS PASSED; host↔guest SHA256 equality for all 13 source files in env.txt). The fixed build is the same slices with this pack's fix.diff applied via patch --fuzz=0 (bidirectionally proven: forward-apply + reverse-apply restores pristine byte-exactly).

Shims (rig_shims.h, rig_types2.h) touch no defect path: allocator with per-object guard pages + free-mode models (guard/zero/poison/groom/plain) + double-free detection, pthread-backed locks with the production lock protocol carried by the verbatim code itself, a fixed-table idr, work plumbing, and copy_to_user into real mapped pages. radeon_mst_helper_funcs (encoder mode-setting callbacks) is a production-named shim table — off every defect path under test.

Driven sequences (exactly what the kernel drives)

• plug/replug: set_mst(true) primary creation (drm_dp_mst_topology.c:2140-2149 + the out_unlock put) → port create + mstb->ports join (:1160-1183) → cbs->add_connector + cbs->register_connector (:1204-1221) → the link-address exit put (:1229-1231).
• unplug: set_mst(false) (:2169-2185) → drm_dp_put_mst_branch_device → drm_dp_destroy_mst_branch_device (kref re-init, port destruction) → drm_dp_put_port → drm_dp_destroy_port (:937, queues) → drm_dp_destroy_connector_work (:3093) → cbs->destroy_connector — all verbatim, krefs balanced exactly as in the kernel (the mstb is freed by the worker's final port put, as upstream designed).
• reader: the verbatim drm_mode_getconnector body; parked inside the ioctl (the fill_modes probe point — in production the widest part of the window: EDID probing over DP AUX) while holding its lookup kref.

Observed (run.log / run.2.log / run.3.log — stable across 3 runs)

Exit codes: 77 = fault classified inside a freed allocation; 78 = double free; 90 = leak accounting.

Primitive and impact (in-kernel translation)

1. UAF read/write under a lookup kref — any unprivileged DRM fd holder in DRM_IOCTL_MODE_GETCONNECTOR (and every other drm_connector_lookup user, e.g. MODE_OBJ_GETPROPERTIES, the setcrtc lookup at drm_crtc.c:729) races the topology destroy worker: the verbatim ioctl body walks/copyouts freed heap (proven: marker bytes copied out → kernel-heap disclosure) and its final drm_connector_put decrements a refcount in freed memory.
2. Indirect call through heap content — with a won same-size reallocation (standard heap grooming; the guest kernel has no hardening), drm_mode_object_put's obj->free_cb is attacker-chosen: the rig drove the benign target (drm_connector_free) and still got the double free; a real groom picks a better target.
3. Write-what-where — the second drm_connector_cleanup's list_del(&connector->head) writes through fully groomed head.prev/head.next (two pointer writes at attacker-chosen addresses; proven in-rig with a chosen destination node).
4. Unbounded kernel memory leak — one radeon_encoder + radeon_encoder_mst per hub flap cycle; after 32 cycles the verbatim encoder-list cap makes every further fake encoder a permanent orphan (never freed even at driver unload), unbounded from a flapping or malicious hub.

Minimum in-kernel outcome of (1)-(3): panic; with grooming: heap corruption with escalation headroom (controlled indirect call + controlled pointer writes). (4) is a deterministic resource-exhaustion DoS.

Why the in-kernel trigger is hardware-gated on this guest (concretely)

radeon_dp_mst_probe requires ASIC_IS_DCE5(rdev) (an Evergreen+ radeon ASIC on the PCI bus), a DP AUX channel with dpcd[DP_DPCD_REV] >= 0x12 and DP_MST_CAP set by the sink, plus radeon_mst=1 — i.e. a real radeon GPU + MST-capable hub. The audit guest has only Bochs VGA (pciconf class 0x030000 chip 0x11111234), no /dev/dri, no drm klds (env.txt). The verbatim rig is exactly the DF-4165/DF-4247-sanctioned evidence class for this situation: production instructions, production kref semantics, driven with the production call sequences; only the hardware-triggered entry (HPD → AUX sideband topology negotiation) is modeled by driving the topology functions directly.

Reproduce

# on the DragonFly guest (tree matching the running kernel at /usr/src):
cd rig && sh ./build.sh /usr/src    # gen + byte-identity proof + make
sh ./run.sh                         # 9 modes x baseline/fixed (see run.log)

DF-4631 VERDICT — radeon MST destroy_connector kref violation

status: reproduced (verbatim-rig evidence class, DF-4165/DF-4247 protocol; 3 stable full-suite runs). In-kernel trigger hardware-gated on this guest (no radeon ASIC / DP MST hub — argued concretely at the end).

1. Root cause (all citations into this tree, byte-verified on the guest)

radeon_dp_destroy_mst_connector (sys/dev/drm/radeon/radeon_dp_mst.c:307-320) tears down an MST child connector with raw drm_connector_cleanup() + kfree() when the topology destroy worker calls it (sys/dev/drm/drm_dp_mst_topology.c:3116, reached from drm_dp_mst_topology_mgr_set_mst(false) → drm_dp_put_mst_branch_device → drm_dp_destroy_mst_branch_device → drm_dp_put_port → drm_dp_destroy_port :937-962 → queued drm_dp_destroy_connector_work :3093-3132) — while this tree's drm core manages connectors with kref lifetime:

• drm_connector_init → __drm_mode_object_add(..., false, drm_connector_free) krefs the object (drm_connector.c:208-210, drm_mode_object.c:34-58);
• drm_connector_free is the kref release and itself calls connector->funcs->destroy() (drm_connector.c:152-160) — i.e. radeon_dp_mst_connector_destroy (radeon_dp_mst.c:248-258) is the only kref-correct full teardown (it also destroys the fake MST encoder);
• drm_mode_getconnector holds a lookup kref across the whole ioctl (drm_connector.c:1734 … :1827), and every other drm_connector_lookup user (e.g. drm_crtc.c:729) does the same;
• this tree's kref_put is a plain atomic_dec_and_test (sys/dev/drm/include/linux/kref.h:64-72) with no underflow protection.

The raw free therefore (a) yanks the object under any outstanding lookup kref, (b) leaves the kref release path (which is what should run) never executed — including its encoder teardown — and (c) if the freed slot is re-groomed, hands drm_mode_object_put an attacker-chosen free_cb + refcount (drm_mode_object.c:184-193).

2. What the rig proved (production code, deterministic interleaving)

The reader is parked inside the verbatim ioctl body at the fill_modes probe point — in production the widest slice of the lookup window (EDID probing over DP AUX) — while the verbatim unplug chain frees the connector. Sequences, accounting and locks are the kernel's own (mstb kref re-init at drm_dp_mst_topology.c:878, port list refs, the worker's final kref_put(&port->kref, drm_dp_free_mst_port) freeing the mstb last).

Controls behaved exactly as production predicts: unplug-before-lookup ⇒ -ENOENT (the idr mutex serializes visibility; the bug is precisely the free-under-held-kref); unplug with no holder ⇒ no fault, raw free, encoder leaked.

The groom is the honest model of a won same-size reallocation: the rig installs the benign call target (drm_connector_free) — a real attacker chooses better — and even so the production code executes a function pointer read out of freed heap, frees a chosen victim object, performs two attacker-addressed pointer writes, and double-kfrees the connector slot.

3. Fix A/B (same rig, same sequences)

fix.diff replaces the raw cleanup+kfree with drm_connector_put():

    drm_connector_unregister(connector);
    radeon_fb_remove_connector(rdev, connector);
-   drm_connector_cleanup(connector);
-
-   kfree(connector);
+   drm_connector_put(connector);   /* kref release path runs
+                    * radeon_dp_mst_connector_destroy(),
+                    * which performs the full teardown
+                    * including the fake MST encoder */

The initial kref from drm_connector_init is the idr/helper reference; the worker's put drops it, so the release (and the full teardown incl. the fake encoder) runs exactly once, at the last reference — deferred past any in-flight ioctl. The finding README's earlier idea of adding a drm_connector_get at registration would leak one reference; the minimal correct fix needs no extra get (verified: fixed unplug-norace frees connector and encoder through the release path, 2 kfrees; baseline frees only the connector raw and leaks the encoder).

Fixed build: 9/9 modes clean — no faults, no double free, no leak marker, encoders reclaimed every cycle — while baseline reproduces on 5/9 (the other four are the two clean controls + the two manifestations of the same raw-free already counted). fix.diff applies to the pristine tree with patch --fuzz=0 and reverse-applies byte-exactly (checker-proven).

Kernel-rebuild validation is N/A on this guest: the path is radeon-ASIC-gated (radeon_dp_mst_probe needs ASIC_IS_DCE5 + DP AUX dpcd[DP_DPCD_REV] >= 0x12 + DP_MST_CAP), and no radeon device exists (env.txt); the A/B above is the same-slice comparison the protocol prescribes for hardware-gated paths.

4. Kernel refs

• sys/dev/drm/radeon/radeon_dp_mst.c:307-320 (raw cleanup+kfree)
• sys/dev/drm/radeon/radeon_dp_mst.c:248-258 (kref-correct funcs->destroy)
• sys/dev/drm/radeon/radeon_dp_mst.c:288,606-653 (fake encoder per add; leaked)
• sys/dev/drm/drm_connector.c:152-160 (release → funcs->destroy)
• sys/dev/drm/drm_connector.c:1734,1827 (ioctl holds lookup kref)
• sys/dev/drm/drm_mode_object.c:126-152 (lookup kref under idr_mutex)
• sys/dev/drm/drm_mode_object.c:184-193 (put → free_cb call)
• sys/dev/drm/drm_dp_mst_topology.c:937-962,3086-3132 (worker chain)
• sys/dev/drm/include/linux/kref.h:64-72 (unprotected dec_and_test)

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.