DF-4625 — poll worker's self-rearm survives cancel_delayed_work_sync → post-cancel execution (mid-suspend MMIO / teardown UAF)

What

output_poll_execute() (sys/dev/drm/drm_probe_helper.c:570-655) re-arms itself at :653-654 (if (repoll) schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD) = 10 s). Upstream Linux relies on cancel_delayed_work_sync() reliably killing self-rearming work. The DragonFly drm shim's cancel_delayed_work_sync() (sys/dev/drm/linux_workqueue.c:415-424) does not:

1. :420-421 it sets canceled and runs callout_cancel(&dwork->timer) first. If the callback is currently executing, the timer is idle — callout_cancel (kern_timeout.c:1032) finds nothing, consumes/clears the CANCEL state and returns.
2. _cancel_work (:340-388) then parks in lksleep waiting for running == false.
3. The running callback (our poll worker) reaches :654 and calls schedule_delayed_work() → callout_reset() arms a fresh timer (nothing blocks a reset; the CANCEL flag was consumed in step 1) — then returns.
4. _cancel_work wakes, sees on_queue == 0 && running == 0 and breaks — a pending timer is invisible to it. cancel_delayed_work_sync returns with the timer armed.
5. Up to 10 s later the timer fires → _delayed_work_fn → queue_work(), which clears work->canceled (linux_workqueue.c:135) and re-queues — the full poll cycle executes after its caller was promised the work is dead.

Victim contract: drm_kms_helper_poll_disable() (:695-700, cancel_delayed_work_sync at :699) and drm_kms_helper_poll_fini() (:735-739) — called from amdgpu suspend (amdgpu_device.c:985, :2813), radeon suspend (radeon_device.c:1233, :1620), i915 (i915_drv.c:1983), and teardown (i915_drv.c:1663, amdgpu dce_v8/10/11/virtual, radeon_display.c:1652, drm_modeset_helper.c:185).

Impact: a full connector-detect cycle racing device suspend (MMIO against a powered-down GPU → hang/panic) or executing on a torn-down drm_device (use-after-free of dev->mode_config / freed connectors).

Build / run (DragonFly guest, fresh boot)

sh build.sh    # verbatim-extracts the shim from /usr/src, builds
               # df4625.ko (baseline) and fixed/df4625fix.ko
sh run.sh      # kldload both; verdicts land in dmesg

The KLD compiles process_all_work, wq_worker_thread, queue_work, _delayed_work_fn, queue_delayed_work, _cancel_work, and the cancel_* trio verbatim against the real kernel primitives (lockmgr / lksleep / callout_reset / callout_cancel / lwkt), then runs a poll-worker-shaped self-rearming delayed work and cancels it mid-callback. The modules deliberately refuse to unload (the verbatim worker thread loops forever — the already-filed DF-1977 wart); reboot after use.

Expected output (dmesg)

baseline: df4625: canceller: cancel_delayed_work_sync() RETURN (timer pending=1 on_queue=0 running=0) df4625: EXEC #2 entered df4625: DF-4625 REPRODUCED: work executed AFTER cancel_delayed_work_sync() returned (exec_count 1 -> 2) fixed: df4625: canceller: cancel_delayed_work_sync() RETURN (timer pending=0 on_queue=0 running=0) df4625: FIX VALIDATED: no execution after cancel_delayed_work_sync() returned within the window (exec_count=1)

The timer pending=1 at cancel-return is the structural miss made directly observable; EXEC #2 is the post-cancel execution.

Files

df4625.c KLD: environment + scenario (fixed variant via -DDF4625_FIXED) build.sh / run.sh exact build/run fix.diff converging cancel_delayed_work_sync (linux_workqueue.c) df4625_extracted.inc the verbatim shim extraction build.log / run.log / env.txt full untrimmed evidence

DF-4625 VERDICT — REPRODUCED (in-kernel KLD, verbatim shim + real primitives)

Status: reproduced / impact: dos (post-cancel execution → mid-suspend probe or teardown UAF) / confidence: certain.

Root cause (traced line by line)

• drm_probe_helper.c:653-654 — output_poll_execute() unconditionally re-arms itself (repoll is true whenever any polled connector exists).
• drm_probe_helper.c:695-700 / :735-739 — drm_kms_helper_poll_disable()/ poll_fini() delegate the kill to cancel_delayed_work_sync().
• linux_workqueue.c:415-424 — the shim cancels the callout before waiting out the running callback; when the callback then re-arms (callout_reset arms a fresh timer; DFBSD callouts only refuse resets while a CANCEL request is still queued — kern_timeout.c:293 checks CALLOUT_CANCEL at wheel-processing time, and _callout_cancel_or_stop on an idle timer consumes/clears the request immediately at kern_timeout.c:1032), nothing re-cancels afterwards.
• linux_workqueue.c:348-385 — _cancel_work() breaks as soon as on_queue == 0 && running == 0; a pending timer is not part of its idle predicate.
• linux_workqueue.c:135 — when the surviving timer fires, queue_work() clears work->canceled, so the full callback re-executes.

Net effect: cancel_delayed_work_sync() returns while the work is guaranteed to run once more (up to DRM_OUTPUT_POLL_PERIOD = 10 s later, drm_probe_helper.c:206). Consumers:

• suspend: amdgpu_device.c:985/:2813, radeon_device.c:1233/:1620, i915_drv.c:1983 → full connector detect (i2c/aux reads + MMIO) against a suspending/suspended GPU → hang/panic.
• teardown: i915_drv.c:1663, amdgpu dce_v8/10/11/virtual fini, radeon_display.c:1652, drm_modeset_helper.c:185 → the work executes on a drm_device being freed → UAF (dev->mode_config reads, connector walks via kref-protected iters on freed memory).

How it was proven (guest, DragonFly 6.5-DEVELOPMENT, real kernel)

A KLD (df4625.c) that sed-extracts the shim functions verbatim from /usr/src/sys/dev/drm/linux_workqueue.c (ranges in build.sh) and compiles them against the real lockmgr/lksleep/callout_reset/ callout_cancel/lwkt-thread kernel primitives. The scenario emulates the poll worker: a callback that re-arms itself with schedule_delayed_work() while a canceller thread runs cancel_delayed_work_sync() mid-callback — the exact interleaving a suspend or poll_fini() hits when it races the 10 s poll cycle (probe cycles run for hundreds of ms, so the overlap is a per-event probability that compounds over suspend/resume cycles).

Decisive dmesg (run.log):

BASELINE:
  canceller: cancel_delayed_work_sync() RETURN (timer pending=1 on_queue=0 running=0)
  EXEC #2 entered
  DF-4625 REPRODUCED: work executed AFTER cancel_delayed_work_sync() returned
FIXED (fix.diff):
  canceller: cancel_delayed_work_sync() RETURN (timer pending=0 on_queue=0 running=0)
  FIX VALIDATED: no execution after cancel_delayed_work_sync() returned

timer pending=1 at cancel-return is the structural miss observed directly in-kernel, not inferred. (The four "interface/module already present" lines in run.log are earlier failed-load attempts of the fixed module before its module id was renamed — kept for honesty.)

Why dos-grade and not higher

The post-cancel execution runs fixed kernel code (the poll worker) on a freed/suspended object; there is no attacker-controlled write primitive. Realistic ceiling: repeatable suspend/resume or driver-teardown crash / hang (needs a drm-driven GPU and timing overlap). The guest's X86_64_GENERIC has no drm compiled in (optional drm), so the real poll path could not be exercised on it — hence the KLD reproduces the exact code and primitives rather than the driver itself.

Fix validation

fix.diff replaces cancel_delayed_work_sync()'s one-shot sequence with a converging loop (_cancel_work until callout_cancel() returns 0 and the work is idle). Convergence argument: any re-arm happens before the callback returns (i.e., before running == false is observed), so the loop's callout_cancel always observes the last-armed timer; a timer firing mid-loop is covered by callout_cancel's synchronous wait on CALLOUT_INPROG (kern_timeout.c). Validated on the same kernel: fixed module returns with pending=0 and no post-cancel execution.

Filed against drm_probe_helper.c (the victim whose drm_kms_helper_poll_disable/poll_fini contract is violated); the causal patch lands in linux_workqueue.c — a file whose pass-1 findings (DF-1976..1980) did not cover this self-rearm cancel miss.

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.