blist API performs no domain validation: count==0 triggers shift-by-64 UB that can clear a whole leaf or poison a live node as a terminator (bm_bighint = -1); blist_create lacks a BLIST_MAXBLKS guard (int64 radix wrap → infinite loop)

Summary

The blist entry points trust their callers completely, and several out-of-domain arguments degrade from harmless to corrupting purely through arithmetic UB: (a) blist_alloc(bl, 0): mask = ~0 >> 64 is undefined (x86 machine shift mod 64 → mask=~0), an all-free leaf matches immediately and bitmap &= ~mask clears all 64 bits while "allocating 0" (silent 64-block capacity leak); a partially-free leaf instead writes bm_bighint = -1 (the TERMINATOR sentinel) onto a live node — blst_meta_alloc/blst_copy then treat it as end-of-tree, permanently hiding all subsequent capacity and truncating later resizes (and it is the only way the mis-written DF-2789 guards could ever fire); (b) 1 << 63 in the count==1 fast path is signed-overflow UB; (c) count > 64 panics by design; (d) blist_create(blocks > 2^61): radix *= 64 wraps to 0 and the while loop spins forever — the only protection is the caller-side clamp. None reachable today (swap passes npages ∈ [1,64]; create/resize/fill root-only and clamped). Filed as hardening so the allocator's domain is enforced where it is defined.

Recommended fix

KKASSERT domain checks at blist_create/alloc/allocat (and count args of free/fill): blocks > 0 && blocks <= BLIST_MAXBLKS, count >= 1 && count <= BLIST_MAX_ALLOC; optionally replace the :408 signed-shift with the unsigned form.

Timeline

• 2026-08-31 Discovered during pass-2 audit of subr_blist.c (GLM 5.3).