DF-2869 — taskqueue tq_running single-slot race → cancel/drain miss running task → UAF

What

taskqueue_run() (sys/kern/subr_taskqueue.c) tracks the currently-executing task in the single queue->tq_running slot and clears it outside the queue spinlock. With ≥2 concurrent runners on one queue the completion of task B clobbers/clears tq_running while task A is still executing, so:

• taskqueue_cancel() fails to return EBUSY for the running task, and
• taskqueue_drain() / taskqueue_drain_simple() return immediately

while ta_func(A) is still on the CPU. A caller following the documented cancel/drain-then-free contract then frees A's task/context → use-after-free (read + write) executed from inside the taskqueue runner.

Concurrent runners exist in-tree: taskqueue_start_threads(count>=2) is an API-supported configuration (vmxnet3 uses nthreads = ntxqueues/2 ≥ 2, sys/dev/virtual/vmware/vmxnet3/if_vmx.c:990-997, and drains those tasks at if_vmx.c:1012), and taskqueue_free() co-runs the queue with the service thread (subr_taskqueue.c:155 racing the worker's run loop).

Build (on the guest as root)

cd /root/poc/tquaf
ln -sf /usr/obj/usr/src/sys/X86_64_GENERIC/device_if.h .
ln -sf /usr/obj/usr/src/sys/X86_64_GENERIC/bus_if.h .
make -m /usr/share/mk SYSDIR=/usr/src/sys

Run

kldload /root/poc/tquaf/tquaf.ko
sleep 6
dmesg | grep tquaf        # then read the serial console for the panic

Expected output (stock kernel — reproduced)

tquaf: queue 0xfffff8011756aec8 started (0)
tquaf: taskqueue_cancel(t1) = 0 while t1 running (0 = contract violated, EBUSY=16 expected)
tquaf: BUG PROVEN: taskqueue_drain(t1) returned while t1 ta_func still executing
tquaf: freeing live task context 0xfffff8008d2e0810
tquaf: freed ctx reallocated at 0xfffff8008d2e0810 (alias YES) magic=deadbeef
tquaf: UAF CONFIRMED: running task sees ctx 0xfffff8008d2e0810 magic=deadbeef (expected cafebabe)
panic: DF-2869: task context freed while task running (magic=deadbeef)
Trace: t1_func() at t1_func+0x9b
       taskqueue_run() at taskqueue_run+0xbb
       taskqueue_thread_loop() at taskqueue_thread_loop+0x5d

The panic backtrace is the proof: taskqueue_run → t1_func executing on memory that was freed and reallocated (objcache LIFO aliasing forced by the harness).

Fixed kernel

taskqueue_cancel returns EBUSY, taskqueue_drain blocks until the func completes → harness prints "NOT REPRODUCED: drain blocked correctly", no panic (see fix.diff / run.fixed.log).

DF-2869 VERDICT — REPRODUCED (panic; memory-corruption primitive proven)

One-line

The single tq_running slot (set at subr_taskqueue.c:407, cleared outside the lock at :411) makes taskqueue_cancel (:429) and taskqueue_drain (:493) blind to concurrently-running tasks whenever ≥2 threads execute taskqueue_run() on one queue; the documented cancel/drain-then-free contract then frees a task whose ta_func is still executing — proven as a deterministic use-after-free with a panic backtrace taskqueue_thread_loop → taskqueue_run → t1_func on freed-and-reallocated memory.

How it reproduces (100% deterministic, no timing needed)

1. taskqueue_start_threads(&tq, 2, ...) — an API-supported configuration (subr_taskqueue.c:548, thread distribution across CPUs at :580-581).
2. Worker A dequeues T1 (slow func: blocks on a flag). tq_running = T1.
3. Worker B dequeues T2 (instant). On completion B executes queue->tq_running = NULL; wakeup(T2); — while T1 is still running.
4. taskqueue_cancel(tq, &T1) returns 0 (should be EBUSY) — T1 != tq_running(NULL).
5. taskqueue_drain(tq, &T1) returns immediately — same check at :493.
6. Caller frees T1's context (the documented pattern), kfree + kmalloc the same size (objcache LIFO ⇒ same address, printed "alias YES").
7. Controller pokes ctx->release (UAF write); T1 resumes and reads ctx->magic == 0xdeadbeef → panic("DF-2869: ...").

Evidence

• run.log / panic.txt: the full sequence above, including tquaf: taskqueue_cancel(t1) = 0 while t1 running and tquaf: BUG PROVEN: taskqueue_drain(t1) returned while t1 ta_func still executing and the panic trace through taskqueue_run+0xbb → t1_func+0x9b.

Primitive characterization (write-capable bug)

The premature-free gives the attacker's teardown path a "free a live kernel object while a CPU is still executing its handler" primitive. In the harness the victim is a 16-byte kmalloc'd context; in real consumers the victim is driver-owned state (e.g. vmxnet3's tx queue drained at if_vmx.c:1012 while its deferred-rx/tx taskqueue runs ≥2 threads, if_vmx.c:990-997). The reallocated memory is read AND written by the running handler before it returns (entered/release/magic), i.e. a slab-groomable UAF read/write of task-owned objects. Escalation to uid=0 requires a consumer whose task context embeds a pointer that the still-running handler dereferences or stores through after the free; with heap grooming (same-zone reallocation) this is the standard "free-while-running" corruption family. No unprivileged in-tree trigger exists on this guest (vmxnet3 teardown needs root; the queue must be a count≥2 or a free-racing queue), so the uid0 chain was not exercised end-to-end — that is a hard blocker of reach, not of the primitive, which is proven here.

Who else co-runs a queue (reachability)

• Any count>=2 queue: API-documented, vmxnet3 in-tree.
• taskqueue_free() itself co-runs the queue with the worker (subr_taskqueue.c:155 calls taskqueue_run while the worker may be inside its own run loop) — every thread-based taskqueue gets transient multi-runner windows during teardown.
• SWI queues are safe from this variant (single global ithread dispatches them, kern_intr.c sched_ithd_soft).

Fix validation

Combined fix (fix.diff in this pack): per-task TASKQ_RUNNING flag set at dequeue and cleared under TQ_LOCK; wakeup(task) after unlock; cancel/drain consult the flag. On the fixed kernel: taskqueue_cancel returns EBUSY(16), taskqueue_drain blocks until the func completes, the harness takes its "NOT REPRODUCED: drain blocked correctly" path, no panic. See run.fixed.log.