lwkt_token_init() on a live token silently drops a held exclusive; lwkt_token_uninit() performs no quiescence check
| Field | Value |
|---|---|
| ID | DF-2818 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N |
| CWE | CWE-667 (missing liveness/quiescence validation) |
| File | sys/kern/lwkt_token.c |
| Lines | 914-927 |
| Area | kern |
| Confidence | speculative |
| Discovered | 2026-08-31 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
lwkt_token_init() unconditionally zeroes t_count and t_ref. If invoked on a token another thread currently holds exclusively, the holder's claim vanishes while it keeps running under the token — a second cpu can then acquire the "exclusive" token (mutual exclusion broken, no diagnostic). lwkt_token_uninit() is an empty function: freeing a token with pending waiters is undetected. Both are caller-misuse enablers with no current in-tree trigger, but precisely the checks that would turn consumer-side lifetime bugs into clean panics instead of silent corruption — even on INVARIANTS kernels.
Recommended fix
KKASSERT(tok->t_count == 0 && tok->t_ref == NULL) at the head of
both functions (uninit currently empty).
Timeline
- 2026-08-31 Discovered during pass-2 audit of lwkt_token.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2818 · 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 808 B | ↓ raw | |
| VERDICT.md | — | 1.8 KB | ↓ raw | |
| build.sh | — | 50 B | view raw | |
| env.txt | — | 509 B | view raw | |
| fix.diff | — | 877 B | view raw | |
| h41.c | — | 14.9 KB | view raw | |
| harness.log | — | 2.0 KB | view raw | |
| manifest.json | — | 542 B | view raw | |
| run.sh | — | 105 B | view raw | |
| verdict.json | — | 2.7 KB | view raw |
DF-2818 — lwkt_token_init on live token drops exclusive (Info-tier hardening verification)
What
lwkt_token_init on live token drops exclusive
Build
cd /root/h41 && make
Run
kldload ./h41.ko; sysctl -w debug.h41.cmd=14
Expected
baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone
A/B one-liner: baseline + fix: trytoken=1 (init-side re-init not containable without ownership marker)
Files
README.md VERDICT.md build.sh env.txt fix.diff h41.c harness.log manifest.json run.sh verdict.json
Shared harness: h41.c (combined KLD, sysctl debug.h41.cmd=N driven).
Full batch context: the fix kernel contains all 41 hardening fixes of
this batch compiled together (build RC=0) and passed the complete A/B
suite plus a clean reboot.
DF-2818 — VERDICT
status: reproduced | reproduced: 1 | impact: none | confidence: certain
Mechanically reproduced on the stock guest across two pinned kernel threads (6-cpu guest): cpu0's thread acquired the token exclusively; cpu1's thread then called lwkt_token_init() on the live token - init unconditionally zeroes t_count/t_ref (lwkt_token.c:914-920) - and lwkt_trytoken() on cpu1 then SUCCEEDED (returned 1) while cpu0 still held the token: mutual exclusion silently broken with no diagnostic (harness T14). lwkt_token_uninit() is empty (no quiescence check). Fix validation was instructive: a KKASSERT in init false-positived at BOOT (rman_init re-inits tokens on recycled non-zeroed memory - the first fix kernel panicked at nexus_probe), so the shipped fix asserts quiescence at UNINIT only (where the token provably came from init) and zeroes the fields; the init-side re-init-of-live-token case cannot be asserted without an ownership marker (documented limitation - needs a state flag to be fully contained).
Fix-validation boot panic (v1)
The first fix kernel (KKASSERT in lwkt_token_init) panicked at boot: panic: assertion "tok->t_count == 0 && tok->t_ref == NULL" failed in lwkt_token_init at lwkt_token.c:918 rman_init() -> nexus_probe() ... rman_init legitimately re-initializes tokens on recycled, non-zeroed memory, so the init-side assert cannot distinguish garbage from a live holder. Shipped fix: uninit-side quiescence KKASSERT + field zeroing; the init-side re-init-of-live-token case needs an ownership marker (T14 on the fix kernel still acquires: documented limitation).
Baseline vs fix kernel
baseline: baseline + fix: trytoken=1 (init-side re-init not containable without ownership marker) fix: behavior changed as designed (see verdict)
Fix verification
not_testableFix v1 (KKASSERT in init) panicked at boot via rman_init/nexus_probe - tokens are legitimately re-initialized on recycled memory. Shipped fix: uninit-side quiescence KKASSERT + field zeroing; init-side silent re-init remains possible without an ownership marker (documented; T14 on the fix kernel still acquires - the uninit assert is not on that path).
Confirmed kernel references
Detail
Exploit chain
re-init of a held token zeroes the holder claim -> second cpu acquires the exclusive token
Evidence (decisive lines)
harness.log T14: holder(cpu0) holds; taker re-init + trytoken=1 (acquired while held); boot-panic of fix-v1 documented in VERDICT.md
PoC changes
none (kthread_create_cpu pinning + lwkt_trytoken avoids any hang risk)
Verified recommended fix
Assert quiescence in lwkt_token_uninit; a full fix needs an initialized-state marker for init
Verdict
Mechanically reproduced on the stock guest across two pinned kernel threads (6-cpu guest): cpu0s thread acquired the token exclusively; cpu1s thread then called lwkt_token_init() on the live token - init unconditionally zeroes t_count/t_ref (lwkt_token.c:914-920) - and lwkt_trytoken() on cpu1 then SUCCEEDED (returned 1) while cpu0 still held the token: mutual exclusion silently broken with no diagnostic (harness T14). lwkt_token_uninit() is empty (no quiescence check). Fix validation was instructive: a KKASSERT in init false-positived at BOOT (rman_init re-inits tokens on recycled non-zeroed memory - the first fix kernel panicked at nexus_probe), so the shipped fix asserts quiescence at UNINIT only (where the token provably came from init) and zeroes the fields; the init-side re-init-of-live-token case cannot be asserted without an ownership marker (documented limitation - needs a state flag to be fully contained).
No comments yet.