cv_destroy performs no waiters/queued-state validation — destroy-with-waiter goes undiagnosed, leaving a stale wchan in td_wchan (divergence from FreeBSD INVARIANTS probe)

Summary

cv_destroy only calls spin_uninit, which is a no-op. It carries no INVARIANTS-mode assertion that no thread is still blocked on — or interlocked-enqueued against — the cv being destroyed. FreeBSD's cv_destroy asserts under INVARIANTS that the associated sleep queue is empty. In the ~100 in-tree consumer files (several user-reachable: /dev/cuse, u4b, drm, ipmi, wlan scan), a destroy-with-live-waiter bug therefore produces no diagnostic at all: the waiter keeps the freed cv pointer as td_wchan, hangs silently (timo=0 cv_wait sleeps forever), and after KVA reuse the stale identity can cross-wake unrelated sleepers at the same address. No memory-safety impact today — _wakeup matches by pointer identity only and never dereferences, and spin_uninit writes nothing — a defense-in-depth/diagnostics divergence. Fix: INVARIANTS empty-check via a kern_synch helper probing gd_tsleep_hash (bare KASSERT(cv_waiters==0) is NOT correct — ghost counts from timeouts are legitimate).

Timeline

• 2026-09-02 Discovered during pass-2 audit of kern_condvar.c (GLM 5.3). Protocol otherwise proven sound (interlock/latch/ghost accounting all killed with citations).