# DF-2785 VERDICT

**Status: reproduced (unprivileged kernel panic → local DoS, certain). Fix validated (fixed).**

## Baseline (stock kernel #0, INVARIANTS): panic in ~3 seconds

First attempt design churned without filling the undo table (0 errors
in 21M iterations — churn threads in lockstep kept only ~2 entries
alive; kept as run.log commentary on iteration counts).  Corrected
churn (persistent 25 filler entries + dip/re-fill cycles, staggered
threads) panicked the guest within ~3s of launch as an unprivileged
user:

```
panic: semop - can't undo undos
cpuid = 3
Trace beginning at frame 0xfffff8011833b888
sys_semop() at sys_semop+0x65d
syscall2() at syscall2+0x11e
Debugger("panic")
```
(serial console; full capture in panic.txt; guest wedged in DDB → down.)

Root cause (sys/kern/sysv_sem.c:998-1006): the SEM_UNDO rollback loop
`panic()`s if a reverse-order rollback adjust fails.  The "reverse
order guarantees we won't run out of space" argument is valid only
single-threaded: `semundo_adjust()` (:219-269) keys entries by
`(semid, semnum)` in the process-shared `p->p_sem_undo` and takes only
`p_token`, per call — nothing serializes one thread's undo vector
against sibling threads of the same process.  Victim vector
`{w,+1,U}{w,-1,U}{x,+1,U}{x,-1,U}`: adjust#1 deletes the entry adjust#0
created (net-zero), so if adjust#2 fails on a full table
(`un_cnt == semume == 25`), the rollback of sops[1] looks up an entry
that is absent **by construction** while the table is full → EINVAL →
panic.  Churn threads only need to re-fill the table inside the
sub-microsecond gap between the victim's adjust#1 and adjust#2.

## Fix validation (patched kernel #1: panic → kprintf + break)

Race re-run for 300+ seconds on the patched kernel:

```
victim : 306184192 iters, 21247 errors        (failure path heavily exercised)
semop: SEM_UNDO rollback lost a race, pid 860 (dmesg)
… 170 occurrences of "lost a race" …          (the exact formerly-panicking path)
guest: up                                      (baseline: dead in ~3s)
```

Every one of the 170 race events would have been the panic on the
stock kernel.  Bad behavior gone: no panic; the condition is logged.

## Impact ceiling

Medium — unprivileged, reliable (seconds) local kernel panic = local
DoS.  `panic()` is an intentional kernel halt, so no memory corruption
beyond the DoS itself; a fuller fix would serialize undo vectors
per-process (mutex across the adjust/rollback phase) rather than only
removing the crash.

## Artifacts

panic.txt (serial console), run.log (baseline narrative + fixed-run
progress), run.fixed.log (patched-kernel run + dmesg count), env.txt,
fix.diff (validated in-guest: build RC=0, installkernel RC=0).