# DF-5844 — VERDICT

**Status: reproduced** (panic / kernel stack memory corruption from an
unprivileged sysctl next-walk; impact capped at `panic` for this rig because
planting the >12-deep tree requires a root-loaded KLD — see Honest scoping).

## Root cause (path:line)

- `sys/kern/kern_sysctl.c:786` — `int newoid[CTL_MAXNAME]` (12 ints; `CTL_MAXNAME = 12`,
  sys/sys/sysctl.h:55) in `sysctl_sysctl_next()`.
- `sys/kern/kern_sysctl.c:719-727` — `sysctl_sysctl_next_ls()` writes `*next =
  oidp->oid_number` (line 727) at `next[level-1]`; `level` starts at 1.
- The `!namelen` branch (kern_sysctl.c:733-744) and the `oidp->oid_number >
  *name` branch (kern_sysctl.c:749-758) recurse into `SYSCTL_CHILDREN(oidp)`
  with `next+1, level+1` **without consuming a name component** in the former
  case, so recursion depth tracks the MIB *tree* depth. No check of `level`
  against `CTL_MAXNAME` exists anywhere in the function.
- `sys___sysctl` caps the user's `namelen` at 12 (kern_sysctl.c:1494), but
  that does not bound this walk: `sysctl_sysctl_next` is reached with
  `namelen = 0` for a bare `{CTL_SYSCTL, CTL_SYSCTL_NEXT}` query, and the
  `!namelen` descent recurses to full tree depth.

Tree depth ≥ 13 ⇒ `newoid[12]`, `newoid[13]`, … are written past the array,
one 32-bit `oid_number` per level, marching up `sysctl_sysctl_next`'s stack
frame (saved registers, saved RBP, return addresses of its callers), then
`SYSCTL_OUT(req, newoid, j * sizeof(int))` (kern_sysctl.c:791) would
additionally *copy out* `j > 12` ints from beyond the array (stack info leak)
if the smash itself didn't fault first.

## Reproduction (baseline, unpatched kernel #0, Jul 2 2026)

1. Guest measured natural MIB depth = **5** (`sysctl -aN | awk -F.` max
   components) — no in-tree subsystem nests >12, so the rig plants one.
2. `deepoid.ko` (root, rig only): 24 nested dynamic nodes, explicit oid
   numbers `0x41414100+i` (chain[12] = 0x4141410c, chain[13] = 0x4141410d, …).
3. Trigger as `nobody`: `/tmp/trigger` — a plain `sysctl({1,3,...})` next-walk
   loop; no privileges needed (read-only walker, no caps check on this path:
   sysctl_root write-gates at kern_sysctl.c:1439-1450 don't apply to reads).

Result (serial console, `panic.txt`):

```
deepoid: loaded 24-deep chain (oid 0x41414100+)
Fatal trap 9: general protection fault while in kernel mode
frame pointer = 0x10:0x4141410d4141410c
Stopped at  sysctl_sysctl_next+0x63:  ret
```

RBP = `0x4141410d4141410c` — literally the planted oid numbers of chain
levels 13 and 12: **proof the OOB writes are fully value-controlled by the
oid creator and land exactly at `newoid[12..13]`**, hitting the saved frame
pointer; the fault is the `ret` in `sysctl_sysctl_next` popping attacker
data. Same panic reproduced twice (root-run and nobody-run) — see
`panic.root-run.txt`, `panic.txt`.

## Primitive characterization (why this matters beyond the rig)

- **What**: ascending, one-int-per-level overwrite of the kernel stack above
  a 48-byte local array, values = oid numbers (fully chosen by whoever can
  create the deep chain), count = depth−12 ints.
- **Where**: fixed offset in `sysctl_sysctl_next`'s frame — saved registers,
  frame pointer, return address of `sysctl_sysctl_next` itself, then callers
  (`sysctl_root`, `userland_sysctl`, syscall trap frame). With depth ~60+ the
  writes reach the trap frame's return-to-user path.
- **Who triggers**: *any* user — `sysctl -aN`, libkvm-based tools, anything
  that walks the MIB. No privilege gate exists on the walker.
- **Honest scoping (hard blocker for uid=0)**: to turn this into
  unpriv→root, the *victim system* must first contain a >12-deep sysctl
  tree, and creating one requires `kldload`/root via `sysctl_add_oid`
  (1,256 kernel callers, none unpriv-triggered; natural depth measured 5).
  So the escalation chain ends at "root must plant the weapon" — on a stock
  system no unprivileged user can build the deep tree. It is a landmine for
  any future subsystem that auto-generates nested oid trees (à la FreeBSD's
  `dev.foo.0.bar` auto-trees), and an immediate kernel-smash for
  third-party modules that nest >12. Severity filed Medium accordingly.

## Fix validation

`fix.diff`: reject `level > CTL_MAXNAME` at `sysctl_sysctl_next_ls` entry
(the too-deep subtree is then reported empty — consistent with the
12-component naming limit). Applied to guest `/usr/src`, kernel rebuilt
(`make nativekernel`, BUILD_RC=0), installed, rebooted (#1, Oct 14 01:16).
Identical rig + identical `su -m nobody -c /tmp/trigger`:

- baseline: Fatal trap 9, RBP = 0x4141410d4141410c, DDB, guest down.
- patched: `walk finished after 1834 oids: No such file or directory`,
  TRIG_RC=0, `sysctl -aN | wc -l` = 1829, guest up. (`fix_validation.log`)

Bad behavior gone; fix confirmed effective.

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.