DF-0079 PoC — /dev/null (and /dev/zero) infinite kernel loop DoS

Status: REPRODUCED (trivial unprivileged local full-system DoS)

A single write(fd, buf, (size_t)1<<32) to world-writable /dev/null (mode 0666) by an unprivileged user pegs one CPU at 100% in kernel context forever. The write() syscall never returns; the process is unkillable from userspace; only a reboot recovers. Forking N copies (one per CPU) wedges all cores.

Root cause (verified in audited master DEV sys/kern/kern_memio.c)

In mmrw(), the per-iteration byte count c is declared u_int (32-bit) at kern_memio.c:225, while iov->iov_len is size_t (64-bit). The /dev/null write path assigns c = iov->iov_len; directly with no clamp (:298); /dev/zero write does the same (:364).

When the caller passes a length whose low 32 bits are zero (e.g. exactly 2³² = 0x100000000), c truncates to 0. After the switch, the bookkeeping at :379-382 performs iov->iov_len -= c (subtracting 0) and uio->uio_resid -= c (subtracting 0), leaving the loop state unchanged. The while (uio->uio_resid > 0 && error == 0) predicate at :232 is still true, so mmrw spins forever in kernel context.

The early if (iov->iov_len == 0) { ... continue; } guard at :234 does NOT trip, because it compares the full 64-bit iov_len (= 2³², not 0).

The upper-layer sys_write does not clamp nbyte below 2³²: it only rejects (ssize_t)nbyte < 0 (sys_generic.c:336), so iov_len = 2³² passes through. Worse, on the /dev/null write path no uiomove/copyin is ever issued, so the user buffer pointer is never validated — the attacker can pass an arbitrary (even unmapped) address; the PoC passes (void *)0x1.

Build & run

cc -o df0079 df0079.c          # or: ./build.sh
./df0079                       # pegs 1 CPU forever; or ./run.sh
./df0079 4                     # fork 4 copies to wedge 4 CPUs

Run as any local user — /dev/null and /dev/zero are mode 0666 (kern_memio.c:842/:847). No privilege required.

Expected result (on a vulnerable kernel)

Each invocation calls write(/dev/null, buf, 0x100000000) and never returns. The kernel thread spins in mmrw at :232. Observation (serial console, since ssh itself gets starved) shows the wedged process in state R0 (running on CPU, not blocked) with cputime climbing ~1.18 s per wall second (= 100% of one core) indefinitely, and top reporting one CPU fully in sys. On a 2-CPU guest a single wedge typically makes the box unresponsive to ssh within ~1 s (the wedged CPU also services the network IRQ). Recovery is a hard reset only.

Verified evidence (in this folder)

• run.log — host-side DoS timeline (ssh unreachable t+1 s) + ps excerpt.
• serial_wedge_capture.txt— per-iteration ps/top from a serial-console watcher (pid 852, UID 1001, STAT R0, cputime 0.50 s → 20.56 s).
• build.log — clean build + /dev/null//dev/zero perms + source excerpt.
• env.txt — guest uname, cc, ncpu, device perms, vulnerable lines.
• VERDICT.md — full narrative + path:line mechanism + fix.
• fix.diff — one-line root-cause fix: widen u_int c → size_t c.
• watch_df0079.sh — serial-console observer (writes ps/top to /dev/ttyd0).
• manifest.json — artifact catalog.

Notes

• The same bug affects /dev/zero write (:364) and /dev/kmem (:264, root-only). The fix in fix.diff (widen c to size_t) closes all three.
• The wedged process cannot be killed (SIGKILL/SIGTERM are never delivered: the thread is in an unyielding kernel loop with no signal-check point), so the only recovery is a reboot.

DF-0079 — VERDICT

Verdict: REPRODUCED — trivial unprivileged local full-system DoS

A single write(/dev/null, buf, (size_t)1<<32) by an unprivileged user (uid 1001, not in wheel) wedges one CPU at 100% in kernel context forever. The syscall never returns, the process is unkillable from userspace, and on a small guest the whole machine becomes unreachable within ~1 second. Forking N copies wedges N cores. Recovery is a hard reset only.

Mechanism (every hop cited path:line, confirmed in audited master DEV)

1. sys_write (sys/kern/sys_generic.c:336) only rejects (ssize_t)nbyte < 0. nbyte = 2³² is positive as a 64-bit ssize_t, so it is accepted. sys_generic.c:340 sets aiov.iov_len = uap->nbyte (= 2³²) and :344 sets auio.uio_resid = uap->nbyte (= 2³²). No clamping anywhere.

2. The write reaches mmwrite → mmrw (sys/kern/kern_memio.c:222). The per-iteration byte count is declared u_int c; (32-bit) at :225.

3. mmrw enters while (uio->uio_resid > 0 && error == 0) at :232. The early guard if (iov->iov_len == 0) { ... continue; } at :234 does NOT fire because the full 64-bit iov_len is 2³², not 0.

4. For /dev/null (minor 2), case 2: at :292 returns early on read (:296-297) and on write executes c = iov->iov_len; at :298 — a direct size_t → u_int truncation. With iov_len = 0x100000000 the low 32 bits are zero, so c = 0. There is no uiomove/copyin on this path (the user buffer pointer (void*)0x1 is never dereferenced), so no EFAULT rescues us.

5. After break at :299, control falls to the bookkeeping at :377-382: iov->iov_base += c (+= 0), iov->iov_len -= c (-= 0 → still 2³²), uio->uio_offset += c (+= 0), uio->uio_resid -= c (-= 0 → still 2³²).

6. The while predicate at :232 is still true (uio_resid == 2³² > 0, error == 0). Steps 3–5 repeat with zero net change to the loop state. mmrw spins forever in kernel context on the calling CPU.

7. The mem cdev is D_MPSAFE | D_QUICK (:85) and mmrw holds no lock while spinning, so the wedge is a pure unyielding tight kernel loop — not a lockup. It never blocks, never calls lwkt_yield/uiomove/tsleep, and never reaches a signal-check point, so: - the thread is stuck in state R (running) consuming ~100% of one CPU; - it cannot be preempted or signalled (SIGKILL never takes effect); - if that CPU also services the network IRQ (vtnet), sshd is starved and the guest becomes unreachable within ~1 s.

/dev/null and /dev/zero are created mode 0666 (:842/:847), so the attack is reachable by any local user. /dev/zero write (case 12, :363-365) has the identical c = iov->iov_len truncation and the same infinite loop. (/dev/kmem :264 has it too but is root-only.)

Reproduced evidence

• serial_wedge_capture.txt — a serial-console watcher (writing ps/top to /dev/ttyd0, which lands in the host boot.log and survives reset) captured the wedged process across 18 iterations. Decisive excerpt: PID PPID STAT UID %CPU TIME COMMAND 852 1 R0 1001 0.0 0:00.50 ./df0079 (t+0.0s) 852 1 R0 1001 0.0 0:01.68 ./df0079 (t+0.7s) ... 852 1 R0 1001 0.0 0:20.56 ./df0079 (t+19.5s) CPU states: 0.0% user, 0.0% nice, 50.0% system, 0.0% interrupt, 50.0% idle STAT R0 = running on CPU (not blocked); UID 1001 = unprivileged maxx; cputime grows ~1.18 s per wall-second = 100% of one of two CPUs; residual never drains. (50% system / 50% idle = one CPU fully wedged; the fork-N variant takes the rest.)
• run.log — host-side timeline: a single detached ./df0079 (one process) made the guest unresponsive to ssh within 1 second; ssh stayed unreachable for the full 10 s observation window. No kernel panic (clean starvation, per boot.log). Only vm.sh reset recovered the guest. Reproduced across three independent runs (each requiring a reset).
• build.log, env.txt — clean build; /dev/null & /dev/zero both crw-rw-rw- (0666); the vulnerable u_int c; decl confirmed at :225.

Exploit chain / weaponization

Not a memory-corruption primitive — there is no corruption, only an infinite loop — so there is no escalation chain. The realistic impact ceiling is reliable unprivileged local full-system denial of service: - One write() per CPU pegs every core at 100% in-kernel and never returns. - The wedged threads are unkillable (no signal-check point), so even an administrator cannot recover short of a reboot. - Trivially scriptable: a one-line attacker (python -c 'import os; os.write(os.open("/dev/null",1),b"x"*(1<<32))' or the C PoC) run by any user, or auto-started at login by a compromised low-priv account, takes the whole machine down indefinitely.

Fix (in fix.diff)

Root-cause, one-line fix: widen the per-iteration byte count from 32-bit to 64-bit so c = iov->iov_len cannot truncate:

--- a/sys/kern/kern_memio.c
+++ b/sys/kern/kern_memio.c
@@ -222,7 +222,7 @@
 mmrw(cdev_t dev, struct uio *uio, int flags)
 {
    int o;
-   u_int c;
+   size_t      c;

With c being size_t, c = iov->iov_len (= 2³²) no longer truncates; the bookkeeping at :380/:382 subtracts the full 2³², draining uio_resid to 0 in a single iteration, so the while predicate at :232 exits and the write returns normally. This closes /dev/null (:298), /dev/zero (:364) and /dev/kmem (:264) in one change. All existing function-argument uses of c (uiomove/read_random/add_buffer_randomness_src at :253/:289/:309/:314/:319/:328/:354/:372) operate on values already bounded by min(…, PAGE_SIZE), so widening c to size_t compiles cleanly and changes no bounded-path behaviour.

This supersedes the finding markdown's per-case c = min(iov->iov_len, PAGE_SIZE) clamp proposal: that also works for /dev/null and /dev/zero but would need separate edits at three sites and would not fix the latent /dev/kmem (:264) truncation. Widening c is the single-change root-cause fix the finding itself names as "cleanest".

PoC changes made during verification

• df0079.c: rewritten with an explanatory header citing every relevant kern_memio.c line, a trigger() helper, and a fork-N mode. The core trigger is unchanged from the original PoC: write(fd, (void*)0x1, 0x100000000ULL).
• Added watch_df0079.sh (serial-console observer), build.sh, run.sh, env.txt, VERDICT.md, this README.md, fix.diff, manifest.json, and the full logs (build.log, run.log, serial_wedge_capture.txt).