DF-2980 — tokenless stopprofclock() in addupc_task() (non-atomic p_flags RMW race)

File: sys/kern/subr_prof.c (pass-2 finding; DF-0251 / DF-0252 known, not affected here) Severity: Medium · Confidence: certain (mechanism reproduced + fix-validated) Class: CWE-667 (improper locking) / CWE-362 (race) — concurrent non-atomic RMW on struct proc::p_flags from the profiling AST/syscall-return path.

What it is

addupc_task() calls stopprofclock(p) at sys/kern/subr_prof.c:145 without holding p->p_token, violating stopprofclock()'s documented contract (sys/kern/kern_clock.c:1303-1305 "caller must hold p->p_token"). stopprofclock() does a non-atomic p->p_flags &= ~P_PROFIL (kern_clock.c:1310; p_flags is a plain int, sys/sys/proc.h:241). Every other caller (sys_profil subr_prof.c:61-76, exec kern_exec.c:226→444, exit kern_exit.c:304→365) holds the token; addupc_task is the sole violator, and both of its call sites (platform/pc64/x86_64/trap.c:231 in userret() and trap.c:507 on the T_ASTFLT/RQF_AST_OWEUPC path) are tokenless.

Amplifier: userret() calls addupc_task() on every syscall exit of a P_PROFIL process. A thread that keeps re-arming profil(2) with an unmapped sample buffer (pr_base in dead user space) makes every copyin() in addupc_task() fault, so the tokenless p_flags &= ~P_PROFIL executes at syscall rate (MHz), entirely unprivileged.

When one of those stale RMW stores lands on top of a token-held writer's store — e.g. PT_ATTACH's p->p_flags |= P_TRACED (sys/kern/sys_process.c:305) or its &= ~(P_TRACED|P_WAITED) clear at detach (sys_process.c:362), or setsugid()'s |= P_SUGID (kern_prot.c:1304, called on setuid exec at kern_exec.c:493) — the concurrent update is annihilated. P_SUGID gates ptrace attach (sys_process.c:202-204), sugid coredumps (kern_sig.c:2543) and ktrace (kern_ktrace.c:680); P_TRACED gates the whole debug relationship; P_CONTINUED gates WCONTINUED reporting. Losing the P_SUGID set on a setuid-root exec would let a same-ruid parent ptrace a root-euid image — a speculative full privesc chain (nanosecond window inside setsugid(); not demonstrated).

PoC (100% unprivileged)

• poc.c — victim child (2 threads) loops profil(0x400000000000, 4 GiB, 0, 1.0) into an unmapped window; the tracer parent (same uid) hammers PT_ATTACH/stop/PT_DETACH. Hit signatures, both false-positive-free:
• HIT1 PT_DETACH == EPERM after a successful PT_ATTACH + observed stop ⇒ the |= P_TRACED set was annihilated (sys_process.c:268-271 gate);
• HIT2 PT_ATTACH == EBUSY immediately after a successful PT_DETACH ⇒ the detach's &= ~(P_TRACED|P_WAITED) clear was annihilated and P_TRACED resurrected (state-verified: child kp_stat=SACTIVE with P_TRACED still set — no tstop() can be in flight while the process is fully running, so the only tokenless p_flags writer in that window is addupc_task→stopprofclock).

Build / run (guest)

cc -O2 -Wall -pthread -o poc poc.c
./poc 300000        # exit 0 = RACE HIT, 2 = no hit within budget

Results

Fix

fix.diff — take p->p_token around the stopprofclock() call in addupc_task() (thread context only; both call sites hold no conflicting token; userret() itself acquires p_token a few lines later at trap.c:247, so this is an established pattern).

Suggested hardening beyond this finding: p_flags has several RMW writers that are not mutually serialized (tstop() clears P_WAITED under the parent's token at kern_synch.c:1368 while ptrace writes under the child's token) — a wider cleanup would make p_flags updates atomic (e.g. atomic_clear_int) or consistently token-interlocked.

DF-2980 — VERDICT

Status: reproduced (unprivileged local race; state corruption of security-relevant p_flags bits demonstrated; fix validated) · Confidence: certain (mechanism), exploit escalation speculative.

Root cause (path:line)

• sys/kern/subr_prof.c:145 — addupc_task() calls stopprofclock(p) with no p->p_token. Contract: sys/kern/kern_clock.c:1303-1305 ("caller must hold p->p_token"). All other callers comply: subr_prof.c:61-63 (sys_profil), kern_exec.c:226/444, kern_exit.c:304/365.
• sys/kern/kern_clock.c:1308-1311 — stopprofclock() does read + non-atomic p->p_flags &= ~P_PROFIL. p_flags is a plain int (sys/sys/proc.h:241); RMWs are plain loads/stores (no lock prefix), so a competing CPU's store landing between a tokenless clear's load and store is silently overwritten.
• Tokenless call sites: platform/pc64/x86_64/trap.c:231 (userret() — runs on every syscall exit of a P_PROFIL process) and trap.c:507 (RQF_AST_OWEUPC AST); vkernel mirrors at platform/vkernel64/x86_64/trap.c:197,405.
• Racing token-held writers on the same word: sys_process.c:305/313 (|= P_TRACED), sys_process.c:362 (&= ~(P_TRACED|P_WAITED)), kern_prot.c:1304 (|= P_SUGID, reached from setuid exec at kern_exec.c:493), kern_sig.c:1286 (|= P_CONTINUED), kern_exit.c:201 (|= P_WEXIT), etc. (Also note tstop() at kern_synch.c:1368 clears P_WAITED under the parent's token — p_flags writers are not even mutually serialized; that broader issue is out of scope for this finding.)

Threat

Any unprivileged process can generate a MHz-rate stream of tokenless p->p_flags &= ~P_PROFIL RMWs: loop profil(2) with pr_base in unmapped user VA — every syscall exit runs userret → addupc_task → copyin(EFAULT) → stopprofclock (trap.c:225-232, subr_prof.c:140-145). Each stale store can annihilate a concurrent token-held update of any other p_flags bit. Security gates affected:

• P_SUGID loss ⇒ ptrace attach check passes (sys_process.c:202-204) for a same-ruid setuid-root image ⇒ speculative full privesc (window ~ns inside setsugid() during exec; chain plausible — exec has no synchronous LWP teardown before kern_exec.c:493 — but not demonstrated).
• P_TRACED loss ⇒ tracee escapes its tracer / debugger state corrupted.
• P_CONTINUED / P_WAITED loss ⇒ wait4(WCONTINUED) accounting corruption.
• P_WEXIT/P_POSTEXIT loss ⇒ exit-path correctness.

Demonstrated impact: deterministic-within-seconds corruption of kernel process state (P_TRACED resurrection / annihilation) by an unprivileged user. No memory corruption: addupc_task's copyin/copyout targets are range-checked by std_copyout/std_copyin (platform/pc64/x86_64/support.s:245-258,295-307), so escalation beyond flag corruption was not pursued further.

Reproduction narrative

1. Built poc.c in guest (cc, unprivileged-capable). Victim child: two threads looping syscall(SYS_profil, (void*)0x400000000000, 0x100000000, 0, 0x10000); tracer parent (same uid): PT_ATTACH → waitpid(stop) → PT_DETACH loop. - First attempt failed: PT_ATTACH re-attach got EBUSY (traced relationship persists until DETACH) → reworked to attach/detach cycle. - Second failure mode (understood, not a hit): multi-threaded victim's straggler tstop() re-clears P_WAITED after waitpid consumed the stop → DETACH EBUSY artifact; handled by re-consuming the re-posted stop event (waitpid(WNOHANG|WUNTRACED)).
2. Baseline (kernel #0, stock INVARIANTS): - run.log: HIT2 after 99310 cycles / 1.9 s — PT_ATTACH EBUSY right after a successful PT_DETACH; state dump kp_stat=2 (SACTIVE), kp_flags=0x1c20 (P_TRACED|P_WAITED|P_PROFIL set) — the child was running with P_TRACED still set. Attribution: while the process is fully running no tstop() can be in flight; the only tokenless p_flags writer active is addupc_task→stopprofclock. - run.2.log: 300000 cycles, no hit (race is probabilistic). - run.3.log: HIT2 after 16166 cycles / 0.33 s (kp_flags=0xc20).
3. Fix validation (fix.diff: lwkt_gettoken/reltoken(&p->p_token) around the stopprofclock() in addupc_task): - make nativekernel + make installkernel in guest → kernel #1 Sep 4 2026. - sanity: normal profiling still accumulates samples (sanity.c, sum > 0). - 3 × 1,000,000 cycles (~49 s ≈ 10× the exposure in which baseline hit twice): zero hits (fix-patched.log).
4. Guest reset to pristine baseline afterwards (vm.sh reset with-src, verified #0 kernel and pristine subr_prof.c md5 974b1875e9983feeb4595c295cd0ad40).

Honest limits

• HIT1 (EPERM flavor: annihilated set rather than annihilated clear) was not observed in the recorded runs; HIT2 is the same defect in the stale-store direction and is state-verified. The EPERM flavor remains expected under longer runs.
• The P_SUGID → ptrace-a-setuid-root-image privesc chain is argued from source, not demonstrated.
• 1-in-3 baseline runs produced no hit within 300K cycles — the defect is a race; reproduction is probabilistic but fast (sub-2 s in both hitting runs).