DF-2848 — taskqgroup_create() heap OOB write (cnt unvalidated vs MAXCPU)

WHAT struct taskqgroup embeds a FIXED array struct taskqgroup_cpu tqg_queue[MAXCPU] (sys/kern/subr_gtaskqueue.c:574). The object is kmalloc'd with sizeof(struct taskqgroup) (subr_gtaskqueue.c:788) and taskqgroup_cpu_create() then writes tqg_queue[i] for EVERY i < cnt with no bound check (subr_gtaskqueue.c:793-797): LIST_INIT (8-byte NULL store), tgc_taskq = fresh gtaskqueue* (8-byte heap-pointer store), tgc_cpu = int. cnt > MAXCPU writes past the allocation.

BUILD (on the guest, as root) cd /root/gtq_oob 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 # -> gtq_oob.ko

RUN kldload /root/gtq_oob/gtq_oob.ko # deterministic proof dmesg | tail -30 # see run.log ps -ax -o comm | grep -c '^gtq_oob_' # threads created kldunload gtq_oob

Impact variant (silent-corruption stressor): kldload /root/poc/gtq_smash.ko # cnt = MAXCPU+2048

EXPECTED (stock kernel) - 16 slots probed; every slot at offset >= 6252 ("[PAST ALLOC]") contains a NON-NULL kernel heap pointer in tgc_taskq written by taskqgroup_cpu_create() past the end of the kmalloc'd object. - slot[256]/[257] show the qgroup's own tail (tqg_lock/tqg_name) being clobbered (tgc_cpu=-2134490742 garbage, thread names beyond gtq_oob_257 turn to garbage). - Guest stays up: the corruption is silent (no slab redzones). - FIXED kernel: "taskqgroup_create: gtq_oob cnt 272 > MAXCPU 256, clamping" printed, all [PAST ALLOC] slots read zero, exactly 256 gtq_oob_* threads exist.

FILES gtq_oob.c deterministic OOB-write proof module (readback probe) gtq_smash.c large-overrun impact variant (MAXCPU+2048 slots) build.log / run.log / run.smash.log / run.fixed.log / fixbuild.log fix.diff verified fix (clamp + loud kprintf) manifest.json / verdict.json

VERDICT — DF-2848 (taskqgroup_create unvalidated cnt -> heap OOB write)

REPRODUCED: YES (deterministic), on the stock INVARIANTS guest kernel (DragonFly 6.5-DEVELOPMENT #0, Thu Jul 2 06:02:54 UTC 2026).

HOW

gtq_oob.ko calls taskqgroup_create("gtq_oob", MAXCPU + 16, 1) and reads the slots [256..271] back through a layout replica (only the leading tqg_queue[] array is probed, which sits at offset 0 of the real opaque struct, so replica offsets are exact on x86_64).

Observed (run.log, stock kernel):

gtq_oob: sizeof(struct taskqgroup) <= 6252 bytes (kmalloc size) gtq_oob: slot[261] off=6264 [PAST ALLOC] tgc_taskq=0xfffff8008bb07198 ... ... (11 consecutive [PAST ALLOC] slots, every one non-NULL) gtq_oob: slot[271] off=6504 [PAST ALLOC] tgc_taskq=0xfffff8008bb075a8 ...

Every [PAST ALLOC] slot holds a freshly allocated struct gtaskqueue * written by taskqgroup_cpu_create() (sys/kern/subr_gtaskqueue.c:592-597) at byte offsets 6264..6527, i.e. 12..384 bytes PAST the end of the kmalloc'd object (allocation upper bound 6252 bytes: 6144-byte array + lock + name + cnt + alignment). The allocation is M_ZERO, so these non-NULL kernel pointers are unambiguously the kernel's own OOB stores. Additionally the first OOB slots clobber the object's own tail: slot[256] readback tgc_cpu=-2134490742 is tqg_lock bytes mixed with the store, and thread naming beyond index 257 degenerates (only 257 well-named threads of 272 created) — tqg_name itself gets overwritten by slot 258's tgc_taskq pointer.

Primitive: ~24 bytes per OOB index of kernel-controlled data (heap pointer + int + NULL) written at attacker-chosen distance past a kmalloc'd object (cnt is a caller-supplied int, unvalidated). A large cnt smashes arbitrarily far (run.smash.log: cnt=MAXCPU+2048, ~48KB overrun, 2304 live taskqueue threads — guest survived 30s; corruption is silent, DFly slab has no redzones).

WHY NOT uid=0 / no panic coaxed

The only caller of taskqgroup_create() in the tree is the TASKQGROUP_DEFINE macro's SYSINIT (softirq group, cnt=ncpus<=MAXCPU), and the whole gtaskqueue/taskqgroup API has ZERO in-tree consumers beyond that boot glue (verified: no users of GROUPTASK_ENQUEUE, taskqgroup_attach/detach/create/bind/drain_all anywhere in sys/). Reaching the bug requires loading a KLD that calls the API — root only. So: certain, deterministic memory-corruption primitive, but no unprivileged trigger exists today; it is a latent API hazard of exactly the DF-0085 family (not re-reported here).

EXPLOIT CHAIN: none (see above — root-gated API misuse; no unpriv path).

FIX VALIDATION

fix.diff clamps cnt into [1, MAXCPU] with a loud kprintf. Rebuilt kernel in-guest (#1: Wed Sep 2 09:11:43 UTC 2026, see fixbuild.log: "Kernel install for X86_64_GENERIC completed", BUILD_OK). Re-running the exact PoC on the fixed kernel (run.fixed.log):

taskqgroup_create: gtq_oob cnt 272 > MAXCPU 256, clamping slot[261..271] ... [PAST ALLOC] tgc_taskq=0 tgc_cpu=0 (all zero) FIXED_THREAD_COUNT=256

Baseline OOB writes GONE on the patched kernel. fix_status: fixed.

FILES: run.log (decisive), run.fixed.log, run.smash.log, fixbuild.log, gtq_oob.c, gtq_smash.c, fix.diff, manifest.json, verdict.json. Kernel refs: sys/kern/subr_gtaskqueue.c:574 (array decl), :788-798 (kmalloc + unbounded loop), :585-598 (taskqgroup_cpu_create stores).