DF-0139 — SLEEPQ_HASH misplaced mask → massive OOB index into sleepq_chains

Verdict: REPRODUCED (code-defect confirmed; latent — dead code at runtime)

The macro defect is real and confirmed by code inspection and a standalone arithmetic harness. The buggy code path is, however, dead code on the current guest: subr_sleepqueue.c exports sleepq_lock()/sleepq_add()/etc. (symbols present in /boot/kernel/kernel) but has zero in-tree callers — the file is a FreeBSD/Linux-KPI compatibility shim awaiting a consumer. So there is no live runtime trigger today; the defect fires the instant any caller is wired up (which is the file's documented sole purpose: "ONLY USE THIS FOR FREEBSD COMPATIBILITY, E.G. THE LINUX KPI").

The bug (sys/kern/subr_sleepqueue.c:82-83)

#define SLEEPQ_HSIZE    1024
#define SLEEPQ_HMASK    (SLEEPQ_HSIZE - 1)            /* 0x3FF, 10 bits */
#define SLEEPQ_HASH(wchan)  ((((uintptr_t)(wchan) >> 10) ^ \
                              ((uintptr_t)(wchan) & SLEEPQ_HMASK)))
#define SLEEPQ_LOOKUP(wchan) &sleepq_chains[SLEEPQ_HASH(wchan)]

The & SLEEPQ_HMASK masks only the second XOR operand (wchan & 0x3FF), not the whole XOR result. wchan >> 10 for any kernel pointer (high virtual address bits 0xffff_8...) yields a ~54-bit value; XOR-ing in 10 low bits leaves all the high bits intact, so the returned hash is a 54-bit value while sleepq_chains has only 1024 (10-bit) slots.

SLEEPQ_LOOKUP() then computes &sleepq_chains[huge] — a wild pointer ~hundreds of petabytes past the array — which sleepq_lock() (line 182) immediately feeds to spin_lock(), and sleepq_wclookup() (line 120) feeds to TAILQ_FOREACH. First call → instant panic or silent corruption of unrelated kernel memory.

Evidence (harness)

sleepq_hash_oob.c replicates the macro byte-for-byte (uintptr_t == unsigned long on the 64-bit kernel) and runs it over 6 realistic kernel wait-channel pointers (kmem direct-map, kernel-text symbols, malloc'd structs, the global array address itself). All 6 produce indices far outside [0,1023]:

0xffff800000000000  -> 0x003fffe000000000  *** OOB ***
0xffffffff80b34000  -> 0x003fffffffe02cd0  *** OOB ***
0xffff8000deadbeef  -> 0x003fffe00037a980  *** OOB ***
(array @ 0x401fc0)  -> 0x00000000000013c7  *** OOB ***   (even a low address overflows!)

SLEEPQ_LOOKUP(0xffff8000deadbeef) lands 576,456,354,373,644,288 bytes past the array start. No live panic is possible because nothing calls the API.

Exploit chain

none — this is a latent code defect, not a memory-corruption primitive reachable from userspace. There is no live caller, so there is no trigger, no slab, no victim object, no uid=0 chain to develop. The realistic impact ceiling if/when Linux KPI is wired up is immediate panic or arbitrary kernel memory corruption on first sleepq use (Critical-grade), but on the current default guest the impact is none (dead code).

Fix

fix.diff adds the missing outer mask so the whole XOR result is reduced to the hash range:

#define SLEEPQ_HASH(wchan)  (((((uintptr_t)(wchan) >> 10) ^ \
                              ((uintptr_t)(wchan) & SLEEPQ_HMASK))) & SLEEPQ_HMASK)

git apply --check passes. This is a one-token (& SLEEPQ_HMASK) fix at the root cause; no caller logic changes.

Fix validation

not_testable: there is no live caller to exercise on a booted guest, so a before/after runtime comparison is impossible. The fix is validated by git apply --check (clean) and by the harness showing the fixed macro (SLEEPQ_HASH_FIXED in the source, column "fixed") returns in-range indices (0x0, 0xd0, 0x180, … all < 1024) for every sample. Building a patched kernel would change no observable runtime behavior because nothing calls the API.