DF-2929 — systimer re-init of a queued timer (via DRM hrtimer wrapper) corrupts gd_systimerq

What

sys/kern/kern_systimer.c:systimer_init_oneshot() (line 359-371) re-initializes a struct systimer with an unconditional bzero() at line 363. If the timer is still armed (SYSTF_ONQUEUE, linked into the owning cpu's gd_systimerq), the bzero erases its node.tqe_next/node.tqe_prev links while the neighbours and possibly the queue head still point at it, and also clears the very SYSTF_ONQUEUE flag that systimer_add()'s KKASSERT at line 148 checks — so the subsequent re-add is silent even on INVARIANTS kernels. The queue is left with ghost links / cycles; the dispatcher (systimer_intr) and systimer_del() then unlink through stale pointers.

The in-tree trigger is the DRM Linux-compat wrapper sys/dev/drm/linux_hrtimer.c:hrtimer_start_range_ns() (line 88-119): it implements Linux hrtimer_start() semantics (re-arm an armed timer is legal Linux API) by calling systimer_init_oneshot() on a possibly-armed timer with no dequeue first. intel_uncore.c:___force_wake_auto() (line 1165-1176) calls fw_domain_arm_timer() → hrtimer_start_range_ns() on every auto-forcewake register access, so any two i915 register accesses within the 1 ms timer window execute the corrupting sequence (routinely, from unprivileged GPU ioctls).

Impact

Kernel memory corruption of the per-cpu timer queue (the queue that drives hardclock/statclock): ghost links, cycles, orphaned nodes; double-dispatch of one-shot timers; wild TAILQ_REMOVE writes through stale tqe_prev pointers on production kernels; demonstrated kernel panics in systimer_intr() and systimer_del() on the INVARIANTS guest.

Reproduce (on the QEMU guest)

# build the KLD harness (as root; it MODULE_DEPENDs on drm.ko)
cd /root/df2929 && make

# control: arm P/st/N one-shots, verify queue, clean up   -> "queue ok"
sysctl kern.df2929_run=1

# raw engine sequence (bzero of queued timer + re-add):   -> "QUEUE CORRUPT"
sysctl kern.df2929_run=2      # + panic "Bad link elm" in systimer_del()

# REAL in-tree wrapper path (hrtimer_start_range_ns twice): -> panic in
# systimer_intr() via pcpu_timer_process_oncpu/splz_timer
sysctl kern.df2929_run=5

Fix

fix.diff — make hrtimer_start_range_ns() delete the pending systimer (on its owning cpu, mirroring hrtimer_cancel()) before re-initializing. Validated: rebuild drm.ko with the fix → same PoC runs clean ×8, no panic, queue integrity ok, exactly one fire per cycle.

DF-2929 VERDICT — reproduced (kernel panic / timer-queue corruption); fix validated

Bottom line

Reproduced on the stock INVARIANTS guest (DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC, 6 vCPU): calling the in-tree DRM wrapper hrtimer_start_range_ns() twice within the timer window — the exact sequence intel_uncore.c:___force_wake_auto() performs on every auto-forcewake i915 register access — corrupts the owning cpu's gd_systimerq and panics the kernel inside the timer dispatcher (systimer_intr() via pcpu_timer_process_oncpu()/splz_timer()). The raw engine sequence (systimer_init_oneshot() on a SYSTF_ONQUEUE-linked timer) shows the corruption structurally: a st<->P traversal cycle (8 revisits in 24 hops) plus a one-sided ghost link, followed by panic: Bad link elm ... prev->next != elm in systimer_del(). Root cause: systimer_init_oneshot() bzero()s a possibly-queued struct systimer (sys/kern/kern_systimer.c:363) and the bzero also erases the SYSTF_ONQUEUE flag that would have made systimer_add()'s KKASSERT (:148) catch the violation — silent even on INVARIANTS kernels.

Why it happens (line-accurate)

1. hrtimer_start_range_ns() #1 → systimer_init_oneshot(&timer->st, ...) (sys/dev/drm/linux_hrtimer.c:115) → timer linked into gd_systimerq (1 ms timeout, SYSTF_ONQUEUE set, neighbours' links point at it).
2. hrtimer_start_range_ns() #2 (same timer, still armed — legal Linux hrtimer_start() semantics, no dequeue performed by the wrapper) → systimer_init_oneshot() → bzero(info, sizeof(struct systimer)) at sys/kern/kern_systimer.c:363: - info->node.tqe_next/tqe_prev cleared while still linked (ghost links), - SYSTF_ONQUEUE cleared → systimer_add()'s KKASSERT at :148 passes.
3. systimer_add() inserts the zeroed node per the new expiry: neighbours keep stale links; with P(st's predecessor) still pointing at st the forward walk cycles (st->P->st->P...), and the timer that was after st is orphaned.
4. On the next timer interrupt the dispatcher dequeues nodes whose back-links are stale → TAILQ_REMOVE through a dangling tqe_prev (a wild write on production kernels; on this INVARIANTS guest the QMD check catches it as "Bad link elm ... prev->next != elm").

Reachability / threat model

• The wrapper is in-tree and its Linux semantics (hrtimer_start on an armed timer) are relied upon by ported drivers; intel_uncore.c:___force_wake_auto (line 1165-1176) hits it on every auto-forcewake register access via fw_domain_arm_timer() (line 74-78, unconditional hrtimer_start_range_ns). On i915 hardware, auto-forcewake register access is driven by ordinary GPU use (rendering / ioctl submission by any user with /dev/dri access).
• Secondary callers with the same shape: i915_pmu.c:132, i915_perf.c:1914, amdgpu/dce_virtual.c:709,732.
• On this QEMU guest there is no i915 device, so the PoC drives the wrapper directly from a KLD harness (kern.df2929_run=5) — root loads the harness, but the executed kernel code path (hrtimer_start_range_ns → systimer_init_oneshot → systimer_add) is the production path.

Reproduced evidence

Baseline (stock drm.ko, stock INVARIANTS kernel):

DF2929 mode=1: ... seen_st=1 ... => queue ok                  (control clean)
DF2929 mode=2: forward hops=24 seen_st=8 seen_p=8 ... => QUEUE CORRUPT
panic: Bad link elm 0xffffffff82600400 prev->next != elm
    systimer_del() at systimer_del+0xd4
    df2929_run() ... sysctl_root ... sys___sysctl
(separate boot, real wrapper path:)
DF2929 mode=5: hrtimer path: ... (dispatcher fires 100us later)
panic: Bad link elm 0xffffffff826005c8 prev->next != elm
cpuid = 4
    systimer_intr() at systimer_intr+0x235
    pcpu_timer_process_oncpu() at pcpu_timer_process_oncpu+0x82
    splz_timer() at splz_timer+0x13

Fix validation (patched drm.ko, same kernel, same harness):

DF2929 mode=5: hops=6 dht.st seen=1 ... => queue ok
DF2929 mode=5: cancelled, dht_fires=1..4      (exactly one fire per run)
... x8 runs, guest stays up, no panic.

Exploit chain (characterization)

Impact on this guest: panic (dispatcher unlink trips the INVARIANTS/QMD check). On production (no-INVARIANTS) kernels the same corruption performs real out-of-bounds queue writes: TAILQ_REMOVE stores *(elm->tqe_prev) = elm->tqe_next through stale tqe_prev values, i.e. a write-what-where-shaped primitive confined to the timer queue's link fields, plus double-dispatch of one-shot callbacks (__hrtimer_function's BUG_ON(taskqueue_enqueue != 0) provides a second panic path) and a potential infinite re-dispatch loop of expired one-shots (clock hang). The corrupted node here lives in driver-owned memory (struct hrtimer.st inside the device structure), so turning the primitive into a full uid=0 chain would additionally require controlling the reused node contents (e.g. a driver struct freed/reallocated under the attacker's influence) — not demonstrated; recorded as the hardening blocker. The memory-safety violation itself (ghost-linked queue, wild unlink) is proven.

Reachability analysis that was killed during pass 2 (negative results)

The cross-CPU systimer_del() hypothesis (stack-allocated systimers in clock_nanosleep1() sys/kern/kern_time.c:506-527 and precise_sleep() sys/kern/kern_event.c:2114-2131, deleted after wakeup) was investigated and killed: _wakeup() (sys/kern/kern_synch.c:1000-1030) always lwkt_schedule()s the sleeper on its own td_gd; the nanosleep path parks the thread via lwkt_deschedule_self(); user-scheduler migration (dfly_acquire_curproc, sys/platform/pc64/x86_64/trap.c:336) only happens at return-to-userland — after systimer_del() ran. Empirically: 1.2M+ ppoll/nanosleep precise-sleep iterations across 6 vCPUs produced zero KKASSERT failures (probe source retained: df2929_ppollrace.c).

Fix

fix.diff (against sys/dev/drm/linux_hrtimer.c): hrtimer_start_range_ns() now deletes the pending systimer first, on its owning cpu (mirroring hrtimer_cancel()'s lwkt_setcpu_self() dance), before re-initializing. Validated as above. Suggested engine-side hardening (separate from this fix, relates to DF-0154): have systimer_init_oneshot()/ _systimer_init_periodic() detect a still-queued timer before the bzero (while the flag is still meaningful).