DF-0850 PoC — Missing interior-node limit validation in ext2_htree_find_leaf

Summary

ext2_htree_find_leaf (sys/vfs/ext2fs/ext2_htree.c:257-347) walks htree interior nodes without validating the node's limit field against the filesystem-computed ext2_htree_node_limit(). A crafted ext2 image with count=limit=0xFFFF in an interior htree node causes an OOB binary-search read of ~512KB past the buffer, leading to kernel panic or silent heap info leak.

Build

# On host (Linux with mke2fs + python3):
dd if=/dev/zero of=ext2_htree.img bs=1M count=8
mke2fs -t ext2 -b 1024 -O dir_index -F ext2_htree.img
# Create testdir + files via debugfs (see craft_htree.py)
python3 craft_htree.py    # produces evil_ext2.img

Run (on DragonFlyBSD guest as root)

kldload ext2fs
vnconfig vn0 /root/evil_ext2.img
mkdir -p /mnt/df0850
mount -t ext2fs -o ro /dev/vn0 /mnt/df0850
stat /mnt/df0850/testdir/f0000_longname_to_force_htree_index_split
# Unpatched: kernel panic (lockmgr: locking against myself)
# Patched:   clean ENOENT (htree returns error, linear scan fallback)

Expected behavior

• Bug present (unpatched #0 kernel): kernel panic in ext2_htree_find_leaf
• Bug fixed (patched ext2fs.ko): lookup returns ENOENT or finds file via linear scan; no panic, no OOB read

Preconditions

• Root mount access (vfs.usermount=0 by default) — admin mounts crafted image
• ext2fs module loaded (kldload ext2fs)
• Threat model: removable media, downloaded VM images, filesystem fuzzing

Files

• craft_htree.py — Python script to craft the malicious ext2 image
• evil_ext2.img — pre-built malicious ext2 image (V1: header.h_blk=0)
• run_poc.sh — shell script wrapper for the PoC
• fix.diff — git-apply-able fix (two checks in ext2_htree_find_leaf)
• VERDICT.md — full analysis and fix validation

DF-0850 — Missing interior-node limit validation in ext2_htree_find_leaf

Verdict: REPRODUCED → FIXED

Status: reproduced (panic / DoS) Impact: panic — kernel panic from crafted ext2 image mount + lookup Confidence: certain Fix: validated (single-fix ext2fs.ko module, panic gone)

Mechanism (line-by-line trace)

The ext2 htree directory-index lookup ext2_htree_find_leaf() in sys/vfs/ext2fs/ext2_htree.c:257-347 walks htree interior nodes without fully validating on-disk metadata:

1. Root level — limit validated (ext2_htree.c:308-310): c if (ext2_htree_get_limit(entp) != ext2_htree_root_limit(ip, rootp->h_info.h_info_len)) goto error; The root's limit is checked against the filesystem-computed value. ✓

2. Root level — count/limit guard (ext2_htree.c:313-315): c cnt = ext2_htree_get_count(entp); if (cnt == 0 || cnt > ext2_htree_get_limit(entp)) goto error; Count is bounded by the validated root limit. ✓

3. Descent into interior node (ext2_htree.c:335-339): c if (ext2_blkatoff(vp, ext2_htree_get_block(found) * m_fs->e2fs_bsize, NULL, &bp) != 0) goto error; entp = ((struct ext2fs_htree_node *)bp->b_data)->h_entries; The code descends into the block pointed to by found. No validation of entp's limit against ext2_htree_node_limit(ip). ✗

4. Next iteration — count/limit guard uses attacker data (ext2_htree.c:313-315): On the next loop iteration, get_limit(entp) reads from the interior node's on-disk header — NOT validated against ext2_htree_node_limit(). An attacker sets both count=0xFFFF and limit=0xFFFF: - cnt (0xFFFF) > get_limit (0xFFFF) → false → passes the check - end = entp + cnt - 1 = entp + 65534 → ~512KB past the 1KB bp->b_data

5. OOB binary-search read (ext2_htree.c:319-325): c while (start <= end) { middle = start + (end - start) / 2; if (ext2_htree_get_hash(middle) > hash_major) // OOB READ Each binary-search probe reads 8 bytes from an ext2fs_htree_entry up to ~512KB past the buffer. The OOB data feeds found = start - 1 → ext2_htree_get_block(found) → ext2_blkatoff() with a garbage block number, causing secondary faults.

Two crash manifestations observed:

• V1 image (header block = 0): Root binary search with count=1 produces found = header entry whose h_blk = 0. ext2_blkatoff(vp, 0, ...) tries to re-lock the root buffer (already locked at line 281) → panic: "lockmgr: locking against myself". Reproduces deterministically.

• V3 image (header block = 573): Root binary search correctly descends into block 573 (interior node). Interior node has count=limit=0xFFFF. Binary search reads ~512KB of OOB kernel heap. The OOB block number produced is non-deterministic — may cause secondary panic or silent OOB read (kernel heap info leak via hash comparison side channel).

PoC

Trigger images

Crafted ext2 images (craft_htree.py) with: - EXT2F_COMPAT_DIRHASHINDEX feature enabled (superblock) - IN_E3INDEX (0x1000) flag on directory inode - htree root: h_ind_levels=1, root limit matching ext2_htree_root_limit - Interior node block: count=0xFFFF, limit=0xFFFF

Build & Run

# On host: craft the image
python3 craft_htree.py    # creates evil_ext2.img

# On guest (as root — mount threat model):
kldload ext2fs
vnconfig vn0 /root/evil_ext2.img
mount -t ext2fs -o ro /dev/vn0 /mnt/df0850
stat /mnt/df0850/testdir/f0000_longname_to_force_htree_index_split
# → panic on unpatched, clean ENOENT on patched

Threat model

Mount-time / lookup parsing of an attacker-controlled ext2 filesystem image. Requires root to mount (vfs.usermount=0) or an admin who mounts a user-supplied image. This is a realistic threat for removable media, downloaded VM images, or filesystem fuzzing.

Exploit chain

This is a DoS / OOB read primitive, not a write primitive. No escalation chain is applicable: - The OOB read leaks kernel heap data via hash comparison side channels - The garbage block number from OOB can trigger secondary panics - No write capability is derived from this bug

Impact ceiling: local DoS (kernel panic) from a crafted ext2 image, plus potential kernel heap info leak.

Fix (fix.diff)

Two targeted checks in ext2_htree_find_leaf:

1. Block 0 re-lock prevention (before descent): c if (ext2_htree_get_block(found) == 0) goto error; Prevents crafted images from causing ext2_blkatoff(vp, 0, ...) to re-lock the root buffer.

2. Interior node limit validation (after descent, mirroring root check): c if (ext2_htree_get_limit(entp) != ext2_htree_node_limit(ip)) goto error; Validates the interior node's on-disk limit against the filesystem-computed value, preventing the count=limit=0xFFFF attack that defeats the cnt > get_limit() guard and causes the OOB binary-search read.

Fix validation

Module SHA256 (patched): 5c7a91ab9ec68fae49e3fc21c5cdea919de7669fcf8eea56b8184ebac6d29674

The fix closes both crash paths. The htree lookup returns -1 on detecting the corrupt image, ext2_htree_lookup returns -1, and the caller falls back to a linear directory scan (which succeeds for valid files, returns ENOENT for missing ones).