DF-2951 VERDICT

Status: not_reproduced (runtime). Code-level protocol violation: certain by inspection. Severity filed: Low, confidence likely.

Why the finding is real (source argument)

1. Protocol: td_ucred is the syscall-context credential, synchronized from p_ucred at user->kernel transition (sys/sys/thread.h:279, :327). cratom_proc (kern_prot.c:1166-1188) documents that racing readers are exactly why the pointer store is p_spin-interlocked — raw unlocked p->p_ucred loads outside that protocol are the violation. The sysctl core itself reads td->td_ucred (kern_sysctl.c:1447); sysctl_hostname deviates.
2. kern_mib.c:222 caches pr from one p->p_ucred load, then :228-229 re-load p->p_ucred (three more loads: the handler argument and the two sizeof-expression operands, evaluation order unspecified). Between any load and its deref, cratom_proc on another thread can drop the last non-cached reference and crfree the cred (crfree → refcount 0 → ucred freed; its cr_prison field then holds whatever the objcache recycler wrote).
3. Consequence scale: pr_host is char[256] (sys/jail.h:118) — the subsequent SYSCTL_OUT copies strlen(pr_host)+1 bytes from a garbage-derived prison pointer to userspace. Realistic outcome: kernel panic (wild read). Theoretical ceiling: 256-byte disclosure if the stale chunk is groomed. Prison-UAF half of the window is dead in practice (prison0 is static; a dynamic prison is pinned by the process's own current cred), so the ucred-object UAF-read is the whole story.
4. Attacker: jailed uid-0 (setgroups allowed in jail → unconditional cratom_proc, kern_prot.c:682; kern.hostname read ungated). Unprivileged non-jail users cannot replace their own p_ucred (no-op setuid/setgid, privileged setgroups), which bounds severity at Low — same actor class and impact ceiling family as DF-0181's jailed-root model, but probabilistic instead of deterministic.

Verification attempt (honest negative)

stress_ucred_race.c: 4 threads looping sysctlbyname("kern.hostname"), 4 threads looping alternating setgroups (forcing cratom replacement every call), run for 3 × 120 s inside a jail as uid 0 on the stock INVARIANTS guest:

• run.log: reads 124,072,534 ; setgroups 153,437,435 ; 0 errors
• run.2.log: reads 119,316,721 ; setgroups 154,727,757 ; 0 errors
• run.3.log: reads 124,101,906 ; setgroups 158,916,561 ; 0 errors

No panic, no wedge, guest stayed up (checked after each run). The race window is a handful of adjacent instructions and the freed ucred chunk is typically immediately re-issued as the next cratom's cred (same objcache, same content), so a userspace-only trigger did not manifest. This is a hardening/robustness fix, not a demonstrable exploit.

Recommended fix (one-liner in spirit)

Use the cached prison once, via the sanctioned thread credential:

    struct prison *pr = NULL;
    if (p) {
        pr = td->td_ucred->cr_prison;
        ...
    }
    if (p && pr) {
        ...
        error = sysctl_handle_string(oidp, pr->pr_host,
            sizeof(pr->pr_host), req);
    }

plus optionally spin_lock(&p->p_spin) around a single td->td_ucred capture if td_ucred is ever NULL here (it is not, for user threads: kern_caps.c:344-350 relies on it).