# DF-2691 — VERDICT

## Bottom line

**REPRODUCED.** An unprivileged local user can leave an `EVFILT_SIGNAL`
knote linked into a `struct proc` that is subsequently freed by `wait()`,
and the later destruction of the kqueue performs `SLIST_REMOVE` on the
freed memory.  Demonstrated twice on fresh boots of the stock
INVARIANTS kernel as a deterministic-enough kernel panic
(`knote_remove+0x33: movq 0x18(%rdx),%rax`, fault address 0x18), by an
unprivileged `close(2)`.

## How it was reproduced (step by step)

1. `kq = kqueue()` in the attacking process P.
2. `c = rfork(RFPROC)` — **without** RFFDG, so the child shares P's fd
   table (`fdshare`, kern_fork.c:557).  This is the only way to reach a
   kqueue from a process other than its creator, because `fdcopy()`
   strips kqueue fds from forked children (kern_descrip.c:2573-2576) and
   SCM_RIGHTS refuses them (uipc_usrreq.c:1799-1802).
3. Child `c` registers `EV_ADD, EVFILT_SIGNAL, ident=j` on `kq`;
   `filt_sigattach()` (kern_sig.c:2667-2679) links the knote into **c's**
   `p_klist` with no reference on c.
4. Child exits; P reaps it: `kern_wait()` → `kfree(p, M_PROC)`
   (kern_exit.c:1336).  `exit1()`'s `KNOTE(&p->p_klist, NOTE_EXIT)`
   (kern_exit.c:601) does **not** detach signal knotes (`filt_signal()`
   only reacts to the NOTE_SIGNAL bit — kern_sig.c:2698), unlike
   `filt_proc()` which detaches proc knotes on NOTE_EXIT
   (kern_event.c:382-391).
5. Repeat 64 times for 64 dangling knotes; spray `exec` of `/bin/sleep`
   with padded argv so `p_args` allocations (same 1280-byte slab class as
   `struct proc`, 1208 bytes) recycle the freed chunks.
6. `close(kq)` → kqueue drain → `filt_sigdetach()` (kern_sig.c:2681-2687)
   → `knote_remove(&kn->kn_ptr.p_proc->p_klist, kn)` on freed memory →
   `SLIST_REMOVE` walks `curelm` = recycled `p_klist` head → fault.

Observed (run 1, cpuid 1 / run 2, cpuid 3):

```
Fatal user address access from kernel mode from kqsig_uaf at ffffffff8063c973
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x18
current process = 4104 / 872
Stopped at knote_remove+0x33: movq 0x18(%rdx),%rax
```

0x18 == `offsetof(struct knote, kn_next)`; the faulting instruction is the
`while (SLIST_NEXT(curelm, kn_next) != elm)` walk with `curelm == NULL`
(the recycled chunk was a fresh `M_ZERO` process, kern_fork.c:444).

## Why the panic is only the read side (primitive characterization)

* **UAF write**: when the freed chunk is *not* recycled,
  `SLIST_REMOVE_HEAD` executes `head->slh_first = elm->kn_next` — the
  kernel writes NULL (or a knote pointer) into freed kernel memory at
  offset 496 of a 1280-class slab chunk.  Silent corruption of whatever
  later reuses that chunk.
* **Controlled-pointer walk**: when recycled, the kernel loads
  `SLIST_FIRST` from recycled content and dereferences it.  The PoC's
  `p_args` spray demonstrates user-controlled bytes landing at exactly
  that offset (needs only the `kern.ps_arg_cache_limit` debug knob to be
  raised; without any knob, other same-class kernel allocations decide
  the value).  A recycled head `X` produces reads at `X+24` and, when the
  walk terminates on `elm`, a write of `elm->kn_next` through the forged
  link.

## Exploit chain (toward uid=0) — analysis, not completed

The write primitive is "NULL or stale-knote-pointer into freed/reused
1280-class chunk at +496" plus "kernel walks a recycled pointer".  A full
chain would need to (a) groom the freed chunk with a forged SLIST whose
`kn_next` chain terminates exactly on the (unknown-address) knote being
removed, converting the final `SLIST_REMOVE_AFTER` store into an
arbitrary-address NULL-write (e.g. over a `struct ucred`'s
`cr_uid/cr_ruid`), and (b) defeat the unknown knote address — no KASLR on
this guest, so a heap-address leak or deterministic slab layout would be
the remaining work.  Not completed within this verification run; the
deterministic unprivileged panic plus the silent freed-memory write are
already sufficient for High severity.

## Fix validation (mandatory for memory-corruption findings)

1. Authored `fix.diff`: `filt_signal()` detaches the knote on NOTE_EXIT
   exactly like `filt_proc()` (PHOLD / knote_remove / KN_DETACHED /
   `kn_ptr.p_proc = NULL` / PRELE), and `filt_sigdetach()` honors
   KN_DETACHED.
2. Applied to the guest's `/usr/src` (patch(1) hunks #1 @2681, #2 @2708),
   rebuilt with `make nativekernel KERNCONF=X86_64_GENERIC` and
   `make installkernel` (build+install completed — guest
   `/tmp/kbuild.log` marker `BUILD_INSTALL_DONE`; log lost to the
   snapshot reset, excerpt in fix_build_excerpt.txt), rebooted into
   `DragonFly 6.5-DEVELOPMENT #1: Sun Aug 30 21:53:26 UTC 2026`.
3. **Baseline**: stock kernel panicked on the first run both times
   (run.log, run.2.log).
4. **Patched**: the exact same PoC ran 5/5 times to "SURVIVED: no panic"
   (fix_validation.log).
5. **Functionality**: EVFILT_SIGNAL still delivers on the patched kernel
   (func.c: `kevent n=1 ident=30 data=1`, `FUNC_OK`).

fix_status: **fixed**.

## Notes

* Guest was returned to the clean-source snapshot after validation.
* The `kern.ps_arg_cache_limit=8192` sysctl (debug knob) is only needed
  for the content-controlled-recycle demonstration; the panic reproduced
  without any dependence on its value.