DF-2950 VERDICT

Status: reproduced (impact=dos, S:C). Confidence: certain.

How it was reproduced

Stock guest, kernel DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 (env.txt). jail(8) created plain jails (no special caps) on the host; commands inside run with uid=0 and the jail's prison.

1. jail / df2950ja 127.0.0.4 /bin/sh -c 'id; sysctl -w kern.securelevel=1' → uid=0(root)... and kern.securelevel: -1 -> 1 rc=0. Path: userland_sysctl (kern_sysctl.c:1569-1576) → sysctl_root:1441 (no CTLFLAG_SECURE on this oid) → :1447 caps_priv_check(td->td_ucred, SYSCAP_NOSYSCTL_WR): cr_uid==0 passes the uid test (kern_caps.c:328), group-2 rewrite (kern_caps.c:337-341) turns the cap into SYSCAP_SENSITIVEROOT, prison_priv_check returns 0 (kern_jail.c:856-857) → handler sysctl_kern_securelvl (kern_mib.c:248-261) has no jail check and level 1 ≥ -1 → securelevel = 1.
2. Host root sysctl -w kern.securelevel=0 → sysctl: kern.securelevel=0: Operation not permitted (sysctl_kern_securelvl's ratchet, kern_mib.c:257-258, applies to host root). The damage is permanent until reboot: CTLFLAG_SECURE sysctls become unwritable (kern_sysctl.c:1441-1444) and every other securelevel-gated kernel path engages. This is a host-wide administration denial-of-service from inside a jail.
3. Same gate lets jailed uid-0 corrupt host-global identity and resource MIBs (run.2.log [3]/[6]): kern.hostid 0→4242, kern.domainname ""→pwned-by-jail, kern.maxposixlocksperuid 32528→1, kern.tls_extra 6144→777 (also kern.bootfile/kernelname and kern.maxprocperuid are in the same class).
4. Control cases behave exactly as the code predicts: jailed non-root → EPERM (caps_priv_check uid test, kern_caps.c:328-331); host unprivileged user → EPERM. The hole is specifically that the gate is jail-blind for uid-0-in-jail.

Relationship to DF-2800

DF-2800 (kern_jail.c) found the same root cause (group-2 blanket allow, meta-group rewrite) for the time syscalls. This finding is the sysctl-write sink: different file (sys/kern/kern_mib.c oids are the demonstrated attack surface), different impact (irreversible securelevel ratchet + host/cross-jail global-state corruption), fixed most naturally at the sysctl core by making CTLFLAG_PRISON mean something (see fix.diff). Not a re-report: DF-2800's scope ends at settimeofday/clock_settime/adjtime/ntp_adjtime.

Side observation

The first run (run.log) wedged the guest after its final step: a jail hostname write without PRISON_CAP_SYS_SET_HOSTNAME returns EPERM from sysctl_hostname while holding the all-CPU sysctl XLOCK (kern_mib.c:217-226) — known DF-0181, still unfixed on this kernel. Captured in df0181_live_corroboration.txt. My finding's evidence (steps [1]-[5]) completed before that wedge.

Fix validation

fix.diff = gate jailed writes on CTLFLAG_PRISON in sysctl_root (kern_sysctl.c, +#include <sys/jail.h> for the jailed() inline, sys/jail.h:158). Applied on a vm.sh reset with-src guest, built with make -j4 nativekernel KERNCONF=X86_64_GENERIC (rc=0), installed, rebooted into #1: Fri Sep 4 00:17:28 UTC 2026. fixtest.log: jailed uid-0 → EPERM for kern.securelevel / kern.hostid / kern.domainname / kern.maxposixlocksperuid, all values unchanged; jail-scoped kern.hostname READ still works; host root writes still work. Baseline reproduced=1, patched reproduced=0 → fix_status=fixed. Guest reset to stock afterwards.

Exploit chain

host runs a jail for an untrusted tenant/service (uid 0 inside the jail = attacker) → sysctl -w kern.securelevel=1 (or higher) → host-global irreversible ratchet: host root cannot lower it; at level ≥1 further CTLFLAG_SECURE knobs lock, /dev/mem closes, immutable flags engage → permanent host administration DoS; additionally hostid/domainname/ bootfile/maxprocperuid corruption leaks across the jail boundary into the host and every other jail. Ceiling for this bug class is host-global state manipulation, not uid=0-on-host: memory-safety is not involved, so no escalation chain beyond the integrity/availability impact exists.