DF-2818
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).
No comments yet.