lwkt_token_swap() lower-bound-only KKASSERTs: <2-token invocation corrupts memory before td_toks_array in non-INVARIANTS kernels
| Field | Value |
|---|---|
| ID | DF-2817 |
| 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-787 (latent, debug-assert-guarded) |
| File | sys/kern/lwkt_token.c |
| Lines | 952-971 |
| 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_swap() validates ref1/ref2 ≥ td_toks_base but never checks ref1 < td_toks_stop. Called with fewer than two held tokens, a production kernel computes ref1/ref2 at &td_toks_array[−1]/[−2] and executes the swap: writing array[−1].tr_tok/tr_count clobbers td_kfpuctx and td_toks_have, and the t_ref fixups dereference garbage and can repoint a genuinely-held token's exclusive ref outside the array (breaking mutual exclusion for all later acquisitions). All current callers are disciplined — defense-in-depth for future buggy callers, where the failure would be silent on production instead of a clean INVARIANTS panic.
Recommended fix
Add the missing upper-bound assertion and an early bail-out (if (ref2
< &td->td_toks_base) return;) — diff in the row above.
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-2817 · 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 831 B | ↓ raw | |
| VERDICT.md | — | 1.2 KB | ↓ raw | |
| build.sh | — | 50 B | view raw | |
| env.txt | — | 509 B | view raw | |
| fix.diff | — | 576 B | view raw | |
| h41.c | — | 14.9 KB | view raw | |
| manifest.json | — | 562 B | view raw | |
| panic.txt | — | 633 B | view raw | |
| run.sh | — | 132 B | view raw | |
| verdict.json | — | 2.7 KB | view raw |
DF-2817 — lwkt_token_swap <2-token memory corruption (INVARIANTS panic) (Info-tier hardening verification)
What
lwkt_token_swap <2-token memory corruption (INVARIANTS panic)
Build
cd /root/h41 && make
Run
kldload ./h41.ko; sysctl -w debug.h41.cmd=15 (PANICS on stock kernel)
Expected
baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone
A/B one-liner: baseline: PANIC (assert) | fix: survives (early bail)
Files
README.md VERDICT.md build.sh env.txt fix.diff h41.c manifest.json panic.txt 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-2817 — VERDICT
status: reproduced | reproduced: 1 | impact: panic | confidence: certain
Reproduced on the stock INVARIANTS guest: the harness took exactly ONE token and called lwkt_token_swap(); lwkt_token.c computes ref2 = td_toks_stop-2 = base-1 and the kernel panicked with 'assertion ref2 >= &td->td_toks_base failed in lwkt_token_swap at lwkt_token.c:955' (full serial trace captured). This proves the API computes out-of-bounds tokrefs when called with fewer than two tokens; on INVARIANTS the lower-bound KKASSERT catches it, on production builds KKASSERT is a no-op (sys/sys/systm.h) and the code proceeds to write tok1/tok2 and counts through base-1/base-2, clobbering memory before td_toks_array (td_kfpuctx / td_toks_have per the layout) and repointing live tokens t_ref outside the array - silent mutual-exclusion break / memory corruption. All in-tree callers pair swap with two live gettokens (verified in pass 2), so this is defense-in-depth. On the fix kernel the same call returns cleanly (production-safe early bail, no panic).
Baseline vs fix kernel
baseline: baseline: PANIC (assert) | fix: survives (early bail) fix: behavior changed as designed (see verdict)
Fix verification
fixedA/B: baseline kernel panicked (assertion at lwkt_token.c:955); fix kernel survives the identical call via the unconditional early-return guard (td->td_toks_stop < &td->td_toks_array[2]) - note td_toks_base is a macro over td_toks_array[0], the first fix attempt used td_toks_base[2] which does not compile.
Confirmed kernel references
Detail
Exploit chain
caller bug: token_swap with <2 held tokens -> production: refs at toks_array[-1]/[-2] -> OOB write of tr_tok/tr_count + garbage t_ref repoint -> mutual exclusion broken (INVARIANTS: clean panic instead)
Evidence (decisive lines)
panic.txt: full panic + backtrace from the serial console; fix kernel: T15 SURVIVED log line
PoC changes
none
Verified recommended fix
Unconditional early return when fewer than two tokens are held
Verdict
Reproduced on the stock INVARIANTS guest: the harness took exactly ONE token and called lwkt_token_swap(); lwkt_token.c computes ref2 = td_toks_stop-2 = base-1 and the kernel panicked with assertion ref2 >= &td->td_toks_base failed in lwkt_token_swap at lwkt_token.c:955 (full serial trace captured). This proves the API computes out-of-bounds tokrefs when called with fewer than two tokens; on INVARIANTS the lower-bound KKASSERT catches it, on production builds KKASSERT is a no-op (sys/sys/systm.h) and the code proceeds to write tok1/tok2 and counts through base-1/base-2, clobbering memory before td_toks_array (td_kfpuctx / td_toks_have per the layout) and repointing live tokens t_ref outside the array - silent mutual-exclusion break / memory corruption. All in-tree callers pair swap with two live gettokens (verified in pass 2), so this is defense-in-depth. On the fix kernel the same call returns cleanly (production-safe early bail, no panic).
No comments yet.