DF-2867 — VERDICT

Finding

ktrsyscall() (sys/kern/kern_ktrace.c:111-137) writes all narg argument words it is handed into the KTR_SYSCALL trace record. On the x86_64 syscall paths, when a syscall with more arguments than the register-passing ABI (regcnt) is invoked and the copyin() of the stack-passed remainder fails, the kernel still calls ktrsyscall() with the full narg — but only regcnt words of sysmsg.extargs were initialized. The unfetched tail is stale kernel stack, and it is appended verbatim to the user-readable trace file.

Sites (all reachable from an unprivileged process): - sys/platform/pc64/x86_64/trap.c:1240-1252 (syscall2, regcnt=6, leaks extargs[6] = 1 word for a 7-arg syscall) - sys/platform/pc64/x86_64/trap.c:1419-1435 (sys_xsyscall indirect path, regcnt=5, leaks extargs[5..6] = 2 words for a 7-arg syscall) - sys/platform/vkernel64/x86_64/trap.c:1079-1093 (vkernel64 syscall2, same as pc64) (the vkernel64 indirect site at trap.c:1246-1253 returns before ktrsyscall and does not leak)

7-arg syscalls exist: mmap (197), sendfile (393), mountctl (468), vmspace_mmap (489) — AS(xxx_args)==7 in sys/kern/init_sysent.c; sys/sys/sysproto.h:530-538 (mmap_args).

Reproduction (baseline — stock kernel)

Guest: DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC (Thu Jul 2 06:02:54 UTC 2026), user maxx (uid 1001, unprivileged).

PoC: ktrleak.c 1. ktrace(2) (SYS_ktrace=45) on own pid with KTRFAC_SYSCALL — allowed by ktrcanset() (self, no P_SUGID, no KTRFAC_ROOT). 2. Phase A (mechanism): a valid raw mmap whose arg7 is fetched from a mapped stack slot grooms extargs[6]=0xAAAA0000DEADAA7F; then a raw mmap with RSP inside a PROT_NONE page — copyin(arg7) fails (EFAULT), yet a KTR_SYSCALL record with narg=7 is emitted whose arg7 equals the groom value that was never fetched. 3. Phase B (kernel data): faulting mmaps in a loop with user-mode delays; timer/trap residue repopulates the stack region holding syscall2's sysmsg; the records capture it.

Results (full logs: run1/2/3.log.txt): - Phase A echo confirmed every run: fault records repeat the groom value. - Phase B: 391/392/393 of 404 samples are kernel-canonical (0xffff...) kernel-stack/heap pointers, e.g. 0xfffff80117e579e0, 0xfffff8008f842dc0 (both above kernel _end=0xffffffff81b25e40 — KVA arena / kernel-stack addresses; value varies across boots). - Deterministic, repeatable, no privileges, no crash; the user simply reads their own trace file afterwards.

Status: reproduced / impact=leak / confidence=certain.

Fix validation

fix.diff zeroes extargs[regcnt..narg) immediately after the register-arg bcopy at all three sites, so a failed user-stack fetch leaves zeros instead of stale stack (6 insertions, git-apply-able, verified git apply --check against the read-only tree).

• Guest reverted via vm.sh reset with-src, patch applied to the guest's /usr/src, kernel rebuilt with make -j6 nativekernel KERNCONF=X86_64_GENERIC (rc=0, -Werror), installed (make installkernel, rc=0) and booted as #1: Wed Sep 2 15:21:48 UTC 2026.
• Re-ran the exact PoC 3x on the patched kernel (fix/patched_run*.log): every fault record now carries arg7=0x0000000000000000 (no groom echo — records [001]/[003] are zero instead of the groom value), summary: total=404 nonzero=2 groom_echoed=0 kernel-canonical=0, RESULT: NOT reproduced, exit 1. Contrast with baseline on stock #0: nonzero=404 groom_echoed=11-13 kernel-canonical=391-393, exit 0.

fix_status: fixed (baseline reproduced=1, patched reproduced=0).

Why this matters

ktrace(2) is available to every unprivileged user for their own processes (the standard ktrcanset self-grant). This turns a routine ktrace -i/debugging feature into a repeatable kernel stack oracle: the attacker chooses which syscall fails and when, sampling stale stack contents at a fixed frame offset. Disclosed material includes kernel text/data/heap/stack pointers (defeats any kernel address-space randomization) and whatever residue prior kernel paths (traps, interrupts, copyins) left at that depth.

Related (not re-reported)

DF-0101 (ktr_header ktr_buf pointer + padding leak) and DF-0102 (ktr_sysret.ktr_eosys / ktr_syscall struct padding) cover other uninitialized bytes in the same record family; this finding is the much larger disclosure channel (full stale kernel-stack words via the argument tail) and a different root cause (trap.c fetch-error path).