sleepq timeout API is broken: documented sleepq_set_timeout() macro cannot compile (undefined tick_sbt/C_HARDCLOCK), sbt-vs-ticks unit confusion, and int64->int truncation into tsleep()
| Field | Value |
|---|---|
| ID | DF-2916 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-681 Incorrect Conversion between Numeric Types |
| File | sys/kern/subr_sleepqueue.c |
| Lines | :300, :331, :336 (macro: sys/sys/sleepqueue.h:117-118) |
| Area | kern |
| Confidence | certain |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
Three independent defects in the timeout path. (1) The documented sleepq_set_timeout(wchan, timo) macro expands to sleepq_set_timeout_sbt((wchan), tick_sbt * (timo), 0, C_HARDCLOCK), but neither tick_sbt nor C_HARDCLOCK exists anywhere in the DragonFly tree (the macro is their only occurrence) — any user of the documented API fails to compile (proven on the guest: both undeclared errors). (2) Unit confusion: :300 stores td->td_sqtimo = sbticks + sbt where sbticks is a plain 64-bit tick counter but the FreeBSD API's sbt parameter is sbintime (1<<28 == 1 s); a FreeBSD-semantics caller asking for 500 ms gets a ~2.68-million-tick sleep (~31 days at hz=100) — effective hang of the calling kernel thread. (3) Truncation: the 64-bit sbintime_t timo expression is passed into tsleep()'s int timo parameter — implicit narrowing wraps large values to arbitrary durations. Latent (zero in-tree callers); the first compat consumer using timeouts either fails to build or hangs. Root-gated. Fix: define the macro in DragonFly terms + explicit clamp/convert before tsleep.
Timeline
- 2026-09-02 Discovered during pass-2 audit of subr_sleepqueue.c (GLM 5.3); compiler-reproduced.
No comments yet.