DF-0046 — PoC

sem_wrap.c — semval (u_short) overflow/wrap via the missing SEMVMX upper-bound in semop/SETVAL/semexit, with wrap-to-0 breaking wait-for-zero (semop(0)) synchronization semantics.

fix_test.c — supplementary test exercising the positive-op and SETVAL paths (used to confirm the fix on the patched kernel).

The bug

SEMVMX (32767) is exported to userland via seminfo and POSIX/SVID requires semop/SETVAL to fail with ERANGE when an operation would make semval exceed SEMVMX. The DragonFly kernel never enforces the upper bound at any of the three write sites:

The negative-sem_op branch (:827) has the lower-bound analogue (if (semptr->semval + sopptr->sem_op < 0)), and the in-tree comment at :160 admits "SEMVMX unused - user param". semval is u_short (:40), so large positive ops wrap past 65535.

Consequences (demonstrated by sem_wrap.c):

1. POSIX violation — semval exceeds SEMVMX with no ERANGE returned (four +32767 ops land semval at 131068 mod 65536 = 65532).
2. Wrap-to-0 breaks mutual exclusion — +32767 + +32767 + +2 wraps semval to exactly 0 (logical value 65536). A process blocked in semop(semnum=0, op=0) (wait-for-zero, semzcnt) is spuriously released even though the logical semaphore value is large and positive — broken SysV semaphore synchronization.

No kernel memory corruption (semval is a self-contained u_short field); impact is IPC-state integrity / POSIX non-compliance / local DoS via broken synchronization. No escalation path (no memory write primitive).

Build & run (unprivileged)

cc -o sem_wrap sem_wrap.c
cc -o fix_test fix_test.c    # supplementary
./sem_wrap

Expected output

BUG present (unpatched #0 kernel)

[1] semval after four +32767 ops = 65532  (SEMVMX=32767, POSIX would have ERANGE'd at op2)
    -> BUG CONFIRMED: semval 65532 > SEMVMX 32767 (no ERANGE)
[2] wait-for-zero child RELEASED after wrap-to-0 (semval logical=65536, u_short=0) -> BUG: spurious release, mutual exclusion broken

FIXED kernel (#1, with fix.diff applied)

sem_wrap: op2 (POSIX says ERANGE; DragonFly allows): Result too large

(fix_test additionally confirms SETVAL also returns ERANGE for val > SEMVMX, and normal small ops still work — no regression.)

DF-0046 — Verdict

Verdict: REPRODUCED (logic bug / POSIX non-compliance / local DoS). Fix VALIDATED.

Summary

The DragonFlyBSD SysV semaphore implementation never enforces the SEMVMX (32767) upper bound that POSIX/SVID requires. semval is a u_short (sys/kern/sysv_sem.c:40); three write sites mutate it without any check against SEMVMX:

The negative-sem_op branch (sys/kern/sysv_sem.c:827) does have the lower-bound analogue (if (semptr->semval + sopptr->sem_op < 0)), confirming the upper-bound omission is the bug, not an intentional design. The in-tree comment at sys/kern/sysv_sem.c:160 itself admits "SEMVMX unused - user param".

Mechanism (trigger → primitive → effect)

1. Trigger — unprivileged user calls semget(IPC_PRIVATE, ...) then semop with large positive sem_op values (each ≤ 32767, the short range). No privilege check beyond the set's IPC mode bits.
2. Primitive — the positive-op branch at :849 does semptr->semval += sopptr->sem_op with no SEMVMX check. Four +32767 ops accumulate 0 + 4×32767 = 131068, which wraps the u_short to 131068 mod 65536 = 65532. The wrap is silent (no ERANGE).
3. Effect (demonstrated two ways): - POSIX violation: semval = 65532 > SEMVMX (32767) with no ERANGE. A POSIX-compliant kernel would have returned ERANGE at the second op. - Wrap-to-0 breaks mutual exclusion: +32767 + +32767 + +2 = 65536 wraps semval to exactly 0 (logical value 65536). A process blocked in semop(0) (wait-for-zero, semzcnt waiter) is spuriously released — the PoC's forked child exits with code 42 (released) where it should have blocked indefinitely. This breaks SysV semaphore mutual exclusion for any consumer that relies on the zero state.

Impact

IPC-state integrity / POSIX non-compliance / local DoS via broken SysV semaphore synchronization. No kernel memory corruption — the wrap stays inside the self-contained u_short field; there is no write primitive, no adjacent-object corruption, no escalation path. Rated Low (matches the finding's severity). The wrap-to-0 spurious-release is the most security-relevant consequence (broken cross-process mutual exclusion), but it requires a victim process sharing the semaphore set and using wait-for-zero semantics.

Exploit chain

none — this is a pure logic/integer bug with no memory-corruption primitive. semval is a self-contained u_short; the wrap does not corrupt adjacent kernel memory. There is no write primitive to convert to control flow, no slab grooming, no function pointer to hijack. The realistic impact ceiling is the wrap-to-0 spurious wakeup demonstrated in observation [2], which is a synchronization-integrity / local-DoS issue.

PoC changes

The original sem_wrap.c made a "rollback leaves non-zero" claim that does not hold (u_short arithmetic is closed under mod 65536, so symmetric add/subtract in the rollback returns to the original value — the rollback correctly lands at 0). I replaced that false claim with a sharper, more security-relevant demonstration: the wrap-to-0 spurious release of a wait-for-zero child, which is the actual broken-mutual-exclusion primitive. Also added a supplementary fix_test.c that exercises both the positive-op and SETVAL paths for use on the patched kernel.

Fix validation (Phase 8)

Authored fix.diff adding SEMVMX enforcement at all three write sites:

1. positive-op (:849): if ((int)semptr->semval + sopptr->sem_op > seminfo.semvmx) { eval = ERANGE; lwkt_relpooltoken(semptr); goto done; } — matches the finding's proposed pattern and the existing negative-branch style.
2. SETVAL (:530): if (real_arg.val < 0 || real_arg.val > seminfo.semvmx) { eval = ERANGE; break; } — also catches the int→u_short truncation case (e.g. val = 70000 would have stored 70000 & 0xffff = 4464).
3. semexit (:1139): clamp to SEMVMX (semexit cannot fail; the process is exiting). Defense-in-depth — once semop and SETVAL are bounded, semexit's input state is always ≤ SEMVMX, so the clamp is a backstop.

Before/after (clean comparison on the same guest):

Patched kernel: DragonFly 6.5-DEVELOPMENT #1: Sun Jul 12 23:47:04 UTC 2026, sha256(/boot/kernel/kernel) = 425bca4973a730ceafb4cda4a71b64cd26e10c45d41e26eb55e26e171243619e. Smoke test (normal -1 op) still works (semval=32766), no regression.

Recommended fix

fix.diff supersedes the finding markdown's proposal (which only patched the positive-op branch). The verified fix covers all three write sites (positive-op, SETVAL, semexit) for a complete bound enforcement. The finding markdown's ## Recommended fix only showed the positive-op hunk and noted "and the analogous check at SETVAL :530 and semexit :1139" — fix.diff implements exactly that, with semexit using a clamp (not ERANGE) since it cannot fail.