kern_ptrace permission checks dereference tracer (and pre-token target) ucred pointers with no crhold and no token — freed-cred read racing cratom_proc (DF-2868 analog in sys_process.c)
| Field | Value |
|---|---|
| ID | DF-2885 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-367 / CWE-416 (read) |
| File | sys/kern/sys_process.c |
| Lines | 153, 202-205 (siblings procfs_mem.c:190, procfs_regs.c:60) |
| Area | kern |
| Confidence | likely |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | memcorrupt |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
kern_ptrace() gates PT_ATTACH (and every op re-gated via CHECKIO/ p_trespass in procfs_domem/doregs/dofpregs/dodbregs) by reading bare p_ucred pointers with no reference taken. The tracer-side curp->p_ucred is never protected at all, and the target-side pointer is unprotected at the pre-token PRISON_CHECK. A sibling thread of the tracer executing any set*uid path replaces p_ucred under p_spin and immediately crfree()s the old credential, so the racing kern_ptrace thread dereferences freed M_CRED memory inside a privilege decision. Honest ceiling: the churner can only materialize creds carrying its own ruid, so a fully-unauthorized attach of a foreign-uid target is not constructible even when the race is won — the defect is the UAF read itself (garbage compares/panic risk) plus stale-cred TOCTOU. Same class as DF-2868 (ktrcanset) — this is the ptrace-path instance. Fix: crhold both creds around the whole permission switch (and the procfs siblings).
Timeline
- 2026-09-02 Discovered during pass-2 audit of sys_process.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2885 · 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 708 B | ↓ raw | |
| VERDICT.md | — | 2.0 KB | ↓ raw | |
| build.sh | — | 76 B | view raw | |
| df2885_ptracecred.c | — | 1.4 KB | view raw | |
| df2885_run.log | — | 216 B | view raw | |
| env.txt | — | 401 B | view raw | |
| fix.diff | — | 1.5 KB | view raw | |
| manifest.json | — | 643 B | view raw | |
| run.sh | — | 81 B | view raw | |
| verdict.json | — | 2.1 KB | view raw |
DF-2885 PoC evidence pack
What
kern_ptrace reads tracer/target credentials without references while a sibling set*uid churns p_ucred (cratom_proc frees the old cred).
Build
cc -o df2885 df2885_ptracecred.c -lpthread
Run
./df2885 (60s as root)
Expected
9.7M PT_ATTACH attempts against cred churn; no crash (window not hit) - run completes with attach counts
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 All logs are full untrimmed captures unless noted. fix.diff is the git-apply-able verified fix (authored after verification; never applied to the audit tree).
DF-2885 - verification verdict
Status: not_reproduced | reproduced: 0 | impact: panic | confidence: likely
Line-accurate confirmation, live race attempted at scale, no observable. The tracer-side credential is dereferenced without a reference: PRISON_CHECK(curp->p_ucred, p->p_ucred) at sys_process.c:153 executes before any token, and the ruid compare + caps_priv_check at :202-205 run under only the TARGET p_token while cratom_proc (kern_prot.c:1165-1189) replaces p_ucred under p_spin and crfree()s the old credential. A root racer (sibling thread flipping seteuid 0/1000 every iteration = forced cratom per call) executing 9,700,294 PT_ATTACH attempts against a child produced no crash and no anomaly: the freed-cred read window is a handful of instructions and INVARIANTS does not trap stale reads of objcache memory. The lifetime defect is source-certain; the practical window makes exploitation implausible; fix (crfhold both creds across the permission switch) compiled into the fix-all kernel and ptrace kept working after boot.
Evidence pointers
df2885_run.log: 9700294 attach attempts, 0 errors, race finished without crash
Kernel references
PoC changes vs the filing sketch
none
Fix
recommendation: crfhold tracer and target creds around the kern_ptrace permission switch
fix status: not_testable
fix compiled in fix-all kernel; ptrace/procfs functional after boot; the race itself cannot be made deterministic
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
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.
Fix verification
not_testablefix compiled in fix-all kernel; ptrace/procfs functional after boot; the race itself cannot be made deterministic
Confirmed kernel references
Detail
Evidence (decisive lines)
df2885_run.log: 9700294 attach attempts, 0 errors, race finished without crash
PoC changes
none
Verified recommended fix
crfhold tracer and target creds around the kern_ptrace permission switch
Verdict
Line-accurate confirmation, live race attempted at scale, no observable. The tracer-side credential is dereferenced without a reference: PRISON_CHECK(curp->p_ucred, p->p_ucred) at sys_process.c:153 executes before any token, and the ruid compare + caps_priv_check at :202-205 run under only the TARGET p_token while cratom_proc (kern_prot.c:1165-1189) replaces p_ucred under p_spin and crfree()s the old credential. A root racer (sibling thread flipping seteuid 0/1000 every iteration = forced cratom per call) executing 9,700,294 PT_ATTACH attempts against a child produced no crash and no anomaly: the freed-cred read window is a handful of instructions and INVARIANTS does not trap stale reads of objcache memory. The lifetime defect is source-certain; the practical window makes exploitation implausible; fix (crfhold both creds across the permission switch) compiled into the fix-all kernel and ptrace kept working after boot.
No comments yet.