# VERDICT — DF-5673

**Finding:** the pc64 IOPL grant issued via `cpu_set_iopl()`
(sys/platform/pc64/x86_64/sysarch.c:52-57, reachable only through
`/dev/io` open at sys/kern/kern_memio.c:193, gated `SYSCAP_RESTRICTEDROOT`
+ `securelevel <= 0`) is unaccounted per-LWP state:

1. **fork inherits it** — `cpu_fork()` copies the parent trap frame verbatim
   (`sys/platform/pc64/x86_64/vm_machdep.c:158-159`), `PSL_IOPL` included.
2. **the last fd close clears an arbitrary, usually wrong LWP** —
   `mmclose` (sys/kern/kern_memio.c:210-212) calls `cpu_clr_iopl()` on
   *whichever LWP happens to close the last reference*; LWPs that inherited
   the grant (forked children, other threads) keep IOPL=3 with no fd open
   anywhere — violating the documented io(4) contract
   ("Any process that holds a file descriptor on /dev/io open will get its
   IOPL bits in the flag register set", share/man/man4/io.4).
3. **privilege drop does not revoke it** — nothing between `cpu_set_iopl()`
   and user mode re-checks the grant: no `PSL_IOPL` clearing exists in the
   setuid/cred-change path; only `exec_setregs` (machdep.c:1481-1490) and
   the `EFL_SECURE` sanitizers at machdep.c:1023 (sigreturn) and
   machdep.c:3025 (ptrace/procfs `set_regs`) touch rflags, and none of those
   runs on `setuid()`.

Threat: a privileged process that opens `/dev/io` (or issues KDENABIO,
syscons.c:1383-1395 — same inline idiom) and later drops privileges, forks
worker children, or passes the fd away leaves **permanent, unrevokable full
ring-3 port I/O** in LWP frames that no longer correspond to any open fd.
This is the state-machine that gate DF-5646-class port hazards behind
privilege; the gate does not close.

## Result: REPRODUCED (baseline), FIXED (patched kernel)

### Baseline (stock ISO kernel `#0 Thu Jul 2 06:02:54 UTC 2026`)

`run.lifecycle.log` + `run.2.log` (3 consecutive runs, identical):

```
[step1] open(/dev/io) ok, IOPL now = 3            <- cpu_set_iopl hit (sysarch.c:54)
[step3] parent closed fd (last close), parent IOPL=0  <- cpu_clr_iopl hit closer (sysarch.c:62)
[step4] child: all /dev/io fds closed, IOPL=3     <- fork inheritance + no revocation
[step5] child: uid=65534 IOPL=3                    <- survives setuid() privilege drop
```

Child closed its inherited fd *before* the parent's last close, so at the
moment of `mmclose` no child fd existed; the child still shows IOPL=3 by
`pushfq` — the grant outlived every fd reference, exactly as predicted from
the code path.

### Negative results (verified live, `run.surface.log`)

- `sysarch` (syscall 165) returns `EOPNOTSUPP` for every cmd (0,1,2,3,101,
  102,103,127,0x1234) as uid 1001 — pc64 has **no** IOPERM/LDT dispatch, no
  copyin, nothing to abuse (sys/platform/pc64/x86_64/sysarch.c:46-49).
- `/dev/io` open as uid 1001 → `EPERM` (priv gate intact,
  kern_memio.c:184-195).
- **sigreturn forge**: `setcontext()` with `uc_mcontext.mc_rflags |= 0x3000`
  is rejected — the guest console shows `sigreturn: rflags = 0x3206`, printed
  only inside the `EFL_SECURE` rejection branch (machdep.c:1023-1026);
  `PSL_USERCHANGE` (sys/cpu/x86_64/include/psl.h:81-82) excludes `PSL_IOPL`.
  The userland SIGSEGV afterwards is DF's setcontext trampoline dying on the
  EINVAL return (no error path), not a kernel fault. Same `EFL_SECURE` check
  covers ptrace/procfs `set_regs` (machdep.c:3025). No unprivileged forge of
  IOPL exists.
- `exec` clears IOPL (`exec_setregs`, machdep.c:1490) — only the no-exec
  paths keep it.

### Fix validation (`fix.diff`, `fix_build.log`, `fix_run.log`)

`fix.diff` strips `PSL_IOPL` from the child trap frame in `cpu_fork()`
(vm_machdep.c, 1 hunk, `git apply --check` clean against sys/). Applied to
the guest's /usr/src copy, `make quickkernel KERNCONF=X86_64_GENERIC`
(6976-line log), `make installkernel`, reboot into custom `#1 Fri Oct 9
19:21:17 UTC 2026`:

```
[step4] child: all /dev/io fds closed, IOPL=0     <- was 3 on baseline
[step5] child: uid=65534 IOPL=0
```

Observed on **two separate boots** of the patched kernel (boot 2 and boot 3)
— the fork-inheritance vector is closed. Residual (documented, out of scope
of the 1-line fix): the *opener* itself still keeps IOPL=3 across its own
`setuid()` until it execs or exits (FreeBSD-documented io(4) semantics for
the opener), and KDENABIO (syscons.c:1394) has the same shape. A complete
fix would track the grant per-LWP and revoke on cred change; that is
upstream-design territory.

### Guest / rig notes

- Guest: `DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026
  X86_64_GENERIC x86_64`, `kern.securelevel: -1`, `/dev/io` `crw------- root
  wheel`. Guest was reset to the clean-source snapshot after validation
  (uname back to `#0`).
- **Rig anomaly (important)**: in this QEMU/KVM host, CPL3 `in/out` at
  IOPL=0 *sometimes succeeds* — it flipped 24/24 faults → 80/80 OK → mixed
  within one shell (`rig-flip.txt`), uncorrelated with uid or handlers.
  The guest kernel never reloads TR after boot (the private-TSS path in
  swtch.s:482-512 is `#if 0 /* JG */`), the TSS descriptor limit is
  `sizeof(tss)-1` (machdep.c:1698) with `tss_iobase = sizeof(tss)`
  (machdep.c:2881) = architectural "no IO bitmap, deny all" — on real
  hardware these accesses always #GP→SIGBUS (trap.c:512-515). The flips are
  therefore a virtual-CPU/rig artifact. Consequence: every "port access
  OK/SIGSEGV" line in the logs is corroboration only; the **decisive
  observable is the RFLAGS IOPL value read via pushfq** (pure kernel-grant
  state), which was deterministic across all runs (3× baseline IOPL=3 chain,
  2× patched IOPL=0).

## Why not higher severity

Entry requires an already-privileged open (RESTRICTEDROOT + securelevel).
The escape is real but post-privilege: persistence/policy violation against
the documented fd-scoped contract, not an unpriv→priv boundary crossing.
Low per the project rubric ("requires … already-privileged user");
CVSS vector recorded for triage comparability.

## 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.