DF-0027 — PoC

wait_leak.c — unprivileged leak of uninitialized kernel stack via wait4(child, &status, WNOHANG, &ru).

The bug

sys_wait4 (sys/kern/kern_exit.c:913-948) declares uninitialized locals int status; (:918) and struct __wrusage wrusage; (:916), calls kern_wait(&status, ..., &wrusage, ...), and copyouts them whenever error == 0 (:942/:945). sys_wait6 does the same and also copies out a siginfo_t.

kern_wait returns error == 0 on the WNOHANG-no-match path (:1427-1431: *res = 0; error = 0; goto done) without writing *status/*wrusage/ *info, and on the WCONTINUED path leaves *wrusage untouched. So a caller with a running (non-waitable) child samples 4 B (status) + ~72 B (wait4 rusage) — up to ~144 B (wait6 wrusage) + ~128 B (siginfo) — of uninitialized kernel stack per call.

Build & run (unprivileged)

cc -o wait_leak findings/poc/DF-0027/wait_leak.c
./wait_leak

Expected output (bug present)

iter  0: status=0x<residue> (LEAKED)  rusage-nonzero-byte (LEAKED)
...
result: N/50 iterations leaked kernel-stack bytes
result: LEAK CONFIRMED

The leaked bytes vary (kernel-stack residue from prior syscalls) — a samplable KASLR/stack-residue oracle.

DF-0027 — wait4/wait6 uninitialized-kernel-stack info leak

Verdict

REPRODUCED → FIXED. Info leak of uninitialized kernel-stack bytes via wait4(child, &status, WNOHANG, &ru) confirmed on the unpatched 6.5-DEVELOPMENT #0 baseline (50/50 iterations leak; ~100+ non-zero bytes per call into struct rusage, plus the 4-byte status field). The single-fix kernel #1 (same tree + fix.diff) closes the leak completely (0/50 across 3 runs).

Mechanism (root cause)

sys_wait4 (sys/kern/kern_exit.c:913-948) declares uninitialized stack locals:

struct __wrusage wrusage;   /* :916  */
int status;                 /* :918  */

calls kern_wait(idtype, id, &status, options, &wrusage, NULL, ...), then copyouts both locals to userland whenever error == 0:

if (error == 0 && uap->status)
    error = copyout(&status, uap->status, sizeof(*uap->status));          /* :942 */
if (error == 0 && uap->rusage) {
    ruadd(&wrusage.wru_self, &wrusage.wru_children);
    error = copyout(&wrusage.wru_self, uap->rusage, sizeof(*uap->rusage)); /* :945 */
}

sys_wait6 (:950-992) is the same shape and additionally copyouts an uninitialized siginfo_t info (:991).

kern_wait (sys/kern/kern_exit.c:1000) returns error == 0 on the WNOHANG-no-waitable-child path without writing *status or *wrusage:

if (options & WNOHANG) {
    *res = 0;
    error = 0;
    goto done;                 /* :1427-1431  -- status/wrusage/info untouched */
}

The WCONTINUED branch (:1388-1419) sets *status = SIGCONT and writes *info but still never writes *wrusage. Therefore any caller that supplies both a running (non-waitable) child and WNOHANG deterministically samples kernel-stack bytes through the wrappers' copyouts — up to 4 B (status) + ~72 B (wait4 rusage) or ~144 B (wait6 __wrusage) + ~128 B (wait6 siginfo) per call.

PoC / evidence

Two reproducers (both as unprivileged maxx, uid 1001):

• wait_leak.c — minimal: prints status=0x… and a leak yes/no per iter, reports N/50 leaked.
• wait_leak_dump.c — sharper: hexdumps the full 144-byte rusage so the varying residue is visible.

Baseline (#0) — bug present

3 consecutive runs of wait_leak all reported 50/50 iterations leaked. The hex dump shows clearly varying kernel-stack residue per iteration (real pointers like 0xffff_f800_8181_…, canaries 0xffff_ffff_ffff_ffff, etc.):

=== iter 0 (r=0) ===
status = 0xffffffff  (user marker was 0xCAFEBABE)
rusage: 121 non-marker/non-zero bytes
rusage raw (144 bytes):
  0000: 7f 70 81 40 00 f8 ff ff 10 40 fa 16 01 f0 ff ff
  0010: 04 39 59 18 01 f8 ff ff 80 75 ce 16 01 f0 ff ff
  ...
  0080: 78 39 59 18 01 f8 ff ff 63 38 d7 01 ff ff ff ff

=== iter 1 (r=0) ===
status = 0xffffffff
rusage: 104 non-marker/non-zero bytes     # different count → real residue
  0000: 7f 7b 81 40 00 f8 ff ff 90 b8 0d 1d 01 f0 ff ff
  ...

Patched (#1) — bug gone

Same binaries, same guest, after fix.diff was applied to the kernel source, rebuilt, and booted:

=== iter 0 (r=0) ===
status = 0x00000000
rusage: 0 non-marker/non-zero bytes
rusage raw (144 bytes):
  0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ...   (all zero)

result: 0/8 iters leaked
result: no residue

3 consecutive runs all reported 0/50 iterations leaked.

Exploit chain

N/A — pure info leak (read-only primitive). No corruption → no escalation chain. Realistic impact ceiling: a samplable KASLR / kernel-stack-residue oracle (this guest has KASLR OFF, so the leak is most useful as a stack-residue ingredient for a separate exploit). Rated Low (same class as DF-0007 / DF-0010).

PoC changes

• Added wait_leak_dump.c — hexdumps the full rusage so the varying leaked bytes are visible in the evidence pack. (The original wait_leak.c was left untouched; it builds and runs cleanly.)

Fix

fix.diff initialises all of kern_wait's output parameters up front, right after argument validation and before any goto done path can leave them untouched:

if (status)
    *status = 0;
if (wrusage)
    bzero(wrusage, sizeof(*wrusage));
if (info)
    bzero(info, sizeof(*info));

This closes both the WNOHANG-no-match path (:1427-1431) and the WCONTINUED wrusage gap (:1388-1419) in one place, at the root cause, without touching the wrappers. Matches the finding's ## Recommended fix proposal in spirit (initialize at top of kern_wait) — supersedes it by dropping the explicit bzero(info, …) only-when-NULL guard into the same ternary shape as the other two params and adding a clarifying comment.

Fix validation (Phase 8)

Both tested with the same wait_leak + wait_leak_dump binaries from the unprivileged maxx account. The fix is deterministic (zero across 3 runs).

Note on install method

/boot is a separate UFS partition (vbd0s1a). Direct cp of a freshly built kernel.stripped over /boot/kernel/kernel produced a kernel the loader refused (EFTYPE → "don't know how to load module 'kernel'"); the loader's command_loadall also unsets kernelname before reading it, so kernel= / kernelname= overrides in loader.conf are silently ignored. The fix-validation kernel was therefore installed as /boot/kernel.alt/kernel (directory form) and selected by adding default_kernel="kernel.alt" to /boot/defaults/loader.conf (must be in the defaults file so it is set before dloader.menu's ifset conditional runs). This is purely a validation-harness detail; the code change under test is the single hunk in fix.diff.