# DF-2823 VERDICT — REPRODUCED

## Bottom line

On a stock DragonFly 6.5-DEVELOPMENT INVARIANTS kernel, an unprivileged user
process that has reached its uid's POSIX-lock limit (`RLIMIT_POSIXLOCKS`
lowered to 2 by itself, or the default `kern.maxposixlocksperuid` reached by
uid-wide lock churn) **cannot release its own byte-range locks piecemeal**:
any partial `F_UNLCK` that clips into an existing own lock fails with
`ENOLCK`. POSIX.1-2008 §2.9.7 requires F_UNLCK of the caller's own locks to
succeed. The whole-file unlock still works (recovery), but a non-root daemon
with a low rlimit that manages locks incrementally gets wedged.

## How it reproduces (path:line)

1. `kern_fcntl` F_SETLK/F_UNLCK → `VOP_ADVLOCK` → `lf_advlock()`
   (sys/kern/kern_lockf.c:195). start/end computed, op dispatched
   (kern_lockf.c:270–271 → `lf_setlock()`).
2. `lf_setlock()` finds `first_match`/`last_match` (caller's own overlapping
   ranges; kern_lockf.c:342–378).
3. Worst-case headroom accounting, kern_lockf.c:510–524:
   ```c
   count = 0;
   if ((flags & F_POSIX) && !unlock_override) {
       if (!lf_match(first_match, type, flags) &&
           !lf_match(last_match, type, flags)) {
           ...
           count = -1;		/* an F_UNLCK clip may split one lock */
       }
       if (count && lf_count_change(owner, -count)) {
           error = ENOLCK;	/* <-- F_UNLCK must not fail here */
           goto do_cleanup;
       }
   }
   ```
   For `F_UNLCK`, `lf_match()` is always false (ranges are F_RDLCK/F_WRLCK,
   the request is F_UNLCK), so `count = -1` whenever the unlock clips at
   least one own lock and is not the whole-range `unlock_override` case
   (kern_lockf.c:487–492).
4. `lf_count_change(owner, +1)` hits the limit check
   (kern_lockf.c:171–173: `diff > 0 && uid != 0 && max != -1 &&
   uip->ui_posixlocks >= max`) and returns 1 **without charging** →
   `error = ENOLCK` for an unlock.
5. The uid-wide `ui_posixlocks` only rolls up from per-cpu pups past ±32
   (`PUP_LIMIT`, sys/sys/resourcevar.h:117; flush at kern_lockf.c:180–184),
   which is why the PoC creates 33+ locks before probing; the 369 ENOLCK
   refusals during filler creation prove the same `ui_posixlocks >= max`
   condition the unlock headroom tests was true.

Observed (run.log): `F_UNLCK [1,2]` (clips own A=[0,1] and B=[2,3]) →
`rc=-1 errno=77 (ENOLCK)`. Subsequent full-range `F_UNLCK(0, len 0)` →
`rc=0` (the `unlock_override` path at kern_lockf.c:490–492 skips the
headroom, which is why close(2)/exit paths still work — impact is bounded).

## Exploit chain

Not a memory-corruption primitive; no escalation chain exists or is needed.
Impact ceiling: a non-root process (self, or any same-uid victim whose lock
count an attacker can inflate — only same-uid creations charge the uid) is
denied piecemeal lock release; recovery requires whole-file unlock or process
exit. Deterministic, no race.

## PoC changes vs the seeded idea

(None — first pack for this finding.) One harness iteration was needed:
the initial gate required ≥33 *filler* successes, but A+B+31 fillers = 33
total charges is exactly what flushes the counter; the corrected gate keys on
`refusals > 0` (which directly proves `ui_posixlocks >= max`). First attempt
preserved in `run.first.log`.

## Fix validation

`fix.diff` authored against the read-only `sys/` tree (add `enforce` flag to
`lf_count_change()`; pass `type != F_UNLCK` at the headroom site). Not
kernel-rebuilt: this is a Low-severity POSIX/DoS finding, not memory
corruption, so the audit contract makes fix validation optional; the diff is
minimal and mechanical (accounting still balanced: F_UNLCK headroom is
charged, only the limit rejection is suppressed).

## Guest state

Clean: temp file unlinked before locking; final whole-range unlock releases
all ranges; no panics (guest stayed up across all 4 runs); `guest_dirty=0`.