lwkt_acquire() spins forever on a wedged owner cpu with no watchdog recovery (wedge-family hardening)
| Field | Value |
|---|---|
| ID | DF-2730 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-834 Excessive Iteration |
| File | sys/kern/lwkt_thread.c |
| Lines | 1394-1407 |
| Area | kern |
| Confidence | likely |
| Discovered | 2026-08-30 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
lwkt_acquire() waits for a migrating thread's owner cpu to clear TDF_RUNNING|TDF_PREEMPT_LOCK in an unbounded loop whose only diagnostic is a once-per-second LOOPMASK kprintf. Compare the two sibling spin sites, both with recovery: lwkt_send_ipiq3's drain wait re-issues the IPI after 10 repeats with smp_sniff(); lwkt_wait_ipiq panics after ~10s to unwedge the system. If the owner cpu is permanently wedged (the DF-2679 family), lwkt_acquire converts that single-cpu wedge into a second permanently-spun cpu with no escape — spinning inside a critical section servicing only incoming IPIs. Defense-in-depth; requires a pre-existing primary defect.
Recommended fix
Mirror lwkt_wait_ipiq's discipline: bounded spin (~10s), diagnostic kprintf with the owner's gd_sample_pc/gd_sample_sp, resched IPI re-issue (smp_sniff-style), then panic('lwkt_acquire') so the system dumps instead of silently multi-cpu spinning.
Timeline
- 2026-08-30 Discovered during pass-2 audit of lwkt_thread.c (GLM 5.3).
No comments yet.