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)
| Field | Value |
|---|---|
| ID | DF-2790 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N |
| CWE | CWE-682 Incorrect Calculation |
| File | sys/kern/subr_blist.c |
| Lines | 188-191, 408, 420-423, 437, 529, 539, 561, 703 |
| Area | kern |
| Confidence | certain |
| Discovered | 2026-08-31 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
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).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2790 · 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 866 B | ↓ raw | |
| VERDICT.md | — | 1.4 KB | ↓ raw | |
| build.sh | — | 50 B | view raw | |
| env.txt | — | 509 B | view raw | |
| fix.diff | — | 1.5 KB | view raw | |
| h41.c | — | 14.9 KB | view raw | |
| harness.log | — | 2.0 KB | view raw | |
| manifest.json | — | 543 B | view raw | |
| run.sh | — | 106 B | view raw | |
| verdict.json | — | 2.8 KB | view raw |
DF-2790 — blist count==0 domain violations (UB shift) (Info-tier hardening verification)
What
blist count==0 domain violations (UB shift)
Build
cd /root/h41 && make
Run
kldload ./h41.ko; sysctl -w debug.h41.cmd=1 2
Expected
baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone
A/B one-liner: baseline: alloc(0)=0 alloc(1)=NONE | fix: alloc(0)=NONE alloc(1)=0 / baseline: alloc(0)=64 (out-of-range) alloc(1)=0 | fix: alloc(0)=NONE alloc(1)=0
Files
README.md VERDICT.md build.sh env.txt fix.diff h41.c harness.log manifest.json run.sh verdict.json
Shared harness: h41.c (combined KLD, sysctl debug.h41.cmd=N driven).
Full batch context: the fix kernel contains all 41 hardening fixes of
this batch compiled together (build RC=0) and passed the complete A/B
suite plus a clean reboot.
DF-2790 — VERDICT
status: reproduced | reproduced: 1 | impact: corruption | confidence: certain
All three claim layers confirmed on the stock guest via the harness (blist(64), count==0): (1) all-free leaf: blist_alloc(bl,0) returns 0 'successfully' and CLEARS the whole 64-bit leaf (mask = ~0>>64 is UB; on x86-64 the mod-64 shift leaves mask=~0); the subsequent alloc(1) returns SWAPBLK_NONE - 64 blocks of capacity silently lost while bl_free still counts them. (2) partially-free leaf: alloc(0) walks j to 64 where the shifted-out mask becomes 0, matches anything, wipes the whole leaf and returns blk+64 - an OUT-OF-RANGE block number; subsequent alloc(1) then hands out block 0 again (double-alloc of freed-but-not-allocated state on the swap blist). (3) blist_create: no BLIST_MAXBLKS guard - while (radix < blocks) with blocks > 2^61 wraps the int64 radix to 0 and loops forever (NOT executed on the guest; arithmetic is exact and the KKASSERT(skip>0) cannot fire before the wrap). On the fix kernel alloc(0) returns SWAPBLK_NONE and alloc(1) succeeds on both leaf states; create gains a domain KKASSERT. In-tree callers pass count in [1,64] and clamped sizes, so latent hardening.
Baseline vs fix kernel
baseline: baseline: alloc(0)=0 alloc(1)=NONE | fix: alloc(0)=NONE alloc(1)=0 / baseline: alloc(0)=64 (out-of-range) alloc(1)=0 | fix: alloc(0)=NONE alloc(1)=0 fix: behavior changed as designed (see verdict)
Fix verification
fixedA/B: baseline T1/T2 show leaf wipe + capacity leak + out-of-range grant; fix kernel returns SWAPBLK_NONE for count<1 at all four entry points and the create-domain KKASSERT compiles.
Confirmed kernel references
Detail
Exploit chain
count==0 -> UB shift -> mask ~0 (or 0 at j=64) -> whole leaf cleared / out-of-range grant blk+64 -> swap-slot double-assignment on the swap blist
Evidence (decisive lines)
harness.log T1: alloc(0)=0 then alloc(1)=NONE (capacity leak); T2: alloc(0)=64 (out-of-range grant) + leaf wipe; fix kernel T1/T2: alloc(0)=NONE, alloc(1)=0
PoC changes
blist_create takes one argument; SWAPBLK_NONE is -2^63 not -1
Verified recommended fix
Guard count domain at blist_alloc/allocat/free/fill and KKASSERT blocks in [1, BLIST_MAXBLKS] in blist_create
Verdict
All three claim layers confirmed on the stock guest via the harness (blist(64), count==0): (1) all-free leaf: blist_alloc(bl,0) returns 0 successfully and CLEARS the whole 64-bit leaf (mask = ~0>>64 is UB; on x86-64 the mod-64 shift leaves mask=~0); the subsequent alloc(1) returns SWAPBLK_NONE - 64 blocks of capacity silently lost while bl_free still counts them. (2) partially-free leaf: alloc(0) walks j to 64 where the shifted-out mask becomes 0, matches anything, wipes the whole leaf and returns blk+64 - an OUT-OF-RANGE block number; subsequent alloc(1) then hands out block 0 again (double-alloc of freed-but-not-allocated state on the swap blist). (3) blist_create: no BLIST_MAXBLKS guard - while (radix < blocks) with blocks > 2^61 wraps the int64 radix to 0 and loops forever (NOT executed on the guest; arithmetic is exact and the KKASSERT(skip>0) cannot fire before the wrap). On the fix kernel alloc(0) returns SWAPBLK_NONE and alloc(1) succeeds on both leaf states; create gains a domain KKASSERT. In-tree callers pass count in [1,64] and clamped sizes, so latent hardening.
No comments yet.