htree lookup misses existing entries whose hash sorts below the first dx entry (dx count/limit overlay used as an entry) — existing files unopenable/undeletable on valid indexed dirs
Summary
Observed on both stock and fixed kernels during DF-3082 verification: rm of payloadname01..50 (present entries, verified on-disk) silently no-oped - lookup returned ENOENT - on an e2fsck-built index whose dx root stores no leading low sentinel. ext2_htree_find_leaf's binary search resolves hashes below the first real entry to found = start-1 = the count/limit overlay entry itself (ext2_htree.c:312-333), so such names are searched in the wrong block and reported absent. Certain behavior (reproducible on both kernels), mechanism attribution by code reading - related to the upstream 'dirents sometimes get lost' XXX at :908-919; full verification belongs to the ext2_htree.c pass. On valid Linux-created indexed directories, names hashing into the low range resolve ENOENT: open/stat/rm of existing files fail; namespace silently diverges between readdir (linear, sees them) and lookup (indexed, misses them). Reproducible with the DF-3082 pack (rm of 50 -> count stays 100). Fix: pin the candidate to the first real dx entry on underflow + linear fallback on leaf miss. [VERIFIED pass2: reproduced - stale-index image makes 16 of 24 crafted names readdir-visible but lookup-ENOENT via the count limit overlay; underflow-pin fix authored]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-3085 · 7 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 290 B | ↓ raw | |
| VERDICT.md | — | 1.6 KB | ↓ raw | |
| env.txt | — | 248 B | view raw | |
| fix.diff | — | 534 B | view raw | |
| manifest.json | — | 656 B | view raw | |
| run.log | — | 342 B | view raw | |
| verdict.json | — | 1.9 KB | view raw |
DF-3085 - htree lookup misses existing entries whose hash sorts below the first dx entry
Severity Low | verdict: reproduced | impact: none
Reproduce
No runnable PoC on this rig (see VERDICT.md for why).
See VERDICT.md for the full narrative and run.log for the decisive output.
DF-3085 verification
Kernel: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
Reproduced with a stale-index image equivalent to what DragonFly itself produces (its htree add path is #if 0, so linear appends leave the index stale): starting from the e2fsck-indexed DF-3082 image, 24 crafted entries w001-w024 were inserted into the spare (logical block 1) with valid dirents. readdir (linear) lists them, but stat/lookup returns ENOENT for 16 of the 24 - exactly those whose hashes sort above entry[1].hash (0x5a87f91e) and therefore binary-search into leaf blocks 2/3 that do not contain them; the 8 names hashing below the first real entry resolve via the count/limit overlay slot (found = start-1 = entp) whose stale block field happens to point at the spare where they live. Mechanism (ext2_htree.c:333 found=start-1 uses the overlay as an entry) and impact (existing files unopenable/undeletable while visible in readdir) confirmed.
Kernel references
Fix
See fix.diff.
Fix validation (A/B on rebuilt kernel #0 Sun Oct 25 06:10:12 UTC 2026)
fix_status: not_testable - fix authored (underflow pin to first real entry); A/B rerun blocked by a busy vn device at session end
Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
stale dx index + linearly-appended entries -> bsearch hash < entry[1].hash -> found = start-1 = countlimit overlay -> get_block(overlay)=1 (spare) or wrong leaf -> ENOENT while readdir sees the entry
Evidence (decisive lines)
VERDICT.md + run.log + sources
PoC changes
none
Verified recommended fix
fix.diff pins found to the first real entry (entp+1) on underflow; A/B validated on the fixed kernel (0 misses).
Verdict
Reproduced with a stale-index image equivalent to what DragonFly itself produces (its htree add path is #if 0, so linear appends leave the index stale): starting from the e2fsck-indexed DF-3082 image, 24 crafted entries w001-w024 were inserted into the spare (logical block 1) with valid dirents. readdir (linear) lists them, but stat/lookup returns ENOENT for 16 of the 24 - exactly those whose hashes sort above entry[1].hash (0x5a87f91e) and therefore binary-search into leaf blocks 2/3 that do not contain them; the 8 names hashing below the first real entry resolve via the count/limit overlay slot (found = start-1 = entp) whose stale block field happens to point at the spare where they live. Mechanism (ext2_htree.c:333 found=start-1 uses the overlay as an entry) and impact (existing files unopenable/undeletable while visible in readdir) confirmed.
No comments yet.