DF-2619 — hammer2 dirent namlen unbounded by chain->bytes (OOB read past 64KB DIO buffer)

• Cited: sys/vfs/hammer2/hammer2_chain.c:5781-5785 (hammer2_chain_dirent_test)
• Verified additionally in: sys/vfs/hammer2/hammer2_vnops.c:723-737 (hammer2_vop_readdir)
• Severity as filed: Low. Verified impact is higher: kernel-memory disclosure to userspace via getdents(2) (127 bytes), and a repeatable kernel panic when the adjacent page is unmapped.

What this pack contains

Build

1. Guest (root): base image per run_2619.sh prerequisites — newfs_hammer2 -L testvol on a 64M vn image, create ONE file with a 255-char name (head -c 255 /dev/zero | tr '\0' 'A'), sync, umount, pull base2619.img to the host.
2. Host: python3 forge_2619.py base2619.img craft2619.img (relocates the file's DIRENT bref to 0x210FF87 = window 0x2100000, offset 0xFF80, radix 7 → chain->bytes=128 < namlen=255; writes the first 128 name bytes into the block; sets CHECK_NONE on the dirent, PFS-inode and sroot brefs; recomputes the volhdr CRC32Cs).
3. Guest: cc -O -o getdents_dump getdents_dump.c && cc -O -o statprobe statprobe.c, push craft2619.img.

Run

vnconfig -c vn0 craft2619.img
mount -o ro -t hammer2 /dev/vn0@testvol /mnt/h2x
./getdents_dump /mnt/h2x          # leak (or panic, layout-dependent)
./statprobe "/mnt/h2x/$(head -c 255 /dev/zero | tr '\0' 'A')"   # OOB compare
umount /mnt/h2x; vnconfig -u vn0

Expected

• Stock kernel, adjacent page mapped (observed): the 255-char dirent name returned by getdents ends with 127 bytes of kernel memory from past the end of the 64KB DIO buffer (see run_stock.log hexdump: ...4141 ×128 then 01 00 … 6f54f378235a0600 …).
• Stock kernel, adjacent page unmapped (observed): fatal trap 12 in memcpy+0x19 (see console_excerpts.txt [A]).
• Control (base2619.img): everything normal, stat succeeds.
• Fixed kernel #2: malformed entry skipped — no garbage tail, no panic, stat → ENOENT; legit long-name dirents on the base image still list and stat fine (fix_run.log).

Trigger privilege: mounting the crafted image requires root (or vfs.usermount=1 with a user-owned vn device); the leak itself (getdents on a world-readable directory of the mounted fs) is available to any unprivileged user afterwards, exactly like prior art DF-2627.

DF-2619 VERDICT

Status: reproduced (impact: kernel memory disclosure to userspace via getdents; panic variant also reproduced). Confidence: certain.

Root cause (line-precise)

hammer2_chain_dirent_test() compares a DIRENT chain's on-media name against a lookup key using the attacker-controlled on-disk bref.embed.dirent.namlen with no bound against the chain's actual data block size (chain->bytes, derived from data_off's radix):

sys/vfs/hammer2/hammer2_chain.c:5781-5790
    if (chain->bref.type == HAMMER2_BREF_TYPE_DIRENT &&
        chain->bref.embed.dirent.namlen == name_len) {
        if (name_len > sizeof(chain->bref.check.buf) &&        /* >64 */
            bcmp(chain->data->buf, name, name_len) == 0) {     /* unbounded */

chain->data points into a 64KB DIO buffer at data_off & ~HAMMER2_OFF_MASK_RADIX (chain.c:1100 chain->data = (void *)bdata ← hammer2_io_data() io.c:555-563). Nothing validates namlen <= chain->bytes:

• chain load (chain.c:920-1105) only checks the window-fit invariant KKASSERT((lbase+lsize-1) & pmask) == pbase (io.c:127) — a radix-7 (128-byte) block at window offset 0xFF80 passes (0xFF80+0x7F = 0xFFFF stays inside the 64KB window) while namlen=255 walks 127 bytes past both the block and (because the block ends exactly at the buffer end) past the DIO buffer itself.

The same unbounded namlen has a second, worse consumer — hammer2_vop_readdir():

sys/vfs/hammer2/hammer2_vnops.c:723-737
    namlen = bref.embed.dirent.namlen;                    /* on-disk, 255 */
    if (namlen <= sizeof(bref.check.buf)) ...
    else { dname = hammer2_xop_gdata(&xop->head)->buf; }  /* DIO+0xFF80 */
    r = vop_write_dirent(&error, uio, ..., namlen, dname); /* -> userspace */

PoC

forge_2619.py (DF-2616 prior-art technique): base image newfs_hammer2 -L testvol + one 255-char-named file; its DIRENT bref (in the PFS root blockset, key = dirhash(name), namlen 255) is relocated to data_off = 0x210FF87 (window 0x2100000, offset 0xFF80, radix 7); the first 128 bytes of the name are written at 0x210FF80 so the compare walks the whole in-buffer range and continues past the buffer; ancestors (dirent bref, PFS inode bref, sroot bref) set to CHECK_NONE (methods=0) and the three volhdr CRC32Cs recomputed, so mount succeeds normally.

What was observed (all on the provided QEMU guest)

1. Leak, stock INVARIANTS kernel #0 (run_stock.log): getdents on the forged mount returns the 255-byte dirent name whose last 127 bytes are the kernel memory located directly after the 64KB DIO buffer — captured bytes include pointer-like 6f 54 f3 78 23 5a 06 00 (LE 0x00065a2378f3546f, repeated), c0 01 00 00 (448), 02 00 00 00 — adjacent buffer-header/cache content. Control image: clean 255×'A' name, stat succeeds.
2. Panic, stock kernel #0 (console_excerpts.txt [A]): same run family, different heap state — Fatal trap 12, supervisor read, page not present at memcpy+0x19 (RIP 0xffffffff80bcaba9 = memcpy, verified via nm), fault VA page-granular = first page after the DIO buffer. The read is the dirent name copy.
3. Panic inside the cited compare, instrumented kernel #1 (console_excerpts.txt [C]): stat() of the 255-char name faults at hammer2_chain_dirent_test+0x89: cmpb %sil,(%rcx,%r8,1) — the per-byte name compare itself reading past the buffer (the instrumented loop is semantically identical to the stock bcmp).
4. Full backtrace, instrumented kernel #1 (console_excerpts.txt [D]): memcpy+0x19 ← hammer2_vop_readdir+0x5c8 — the vnops.c:729 vop_write_dirent copy of namlen bytes from chain->data->buf.

Threat model: mounting the crafted image needs root (or vfs.usermount=1 with an owned device — same precondition as all hammer2-image findings, incl. prior art DF-2616/17/18/20/27); the getdents disclosure itself is then available to any user with read access to the directory. Real-world trigger without a crafted image: on-media corruption of a hammer2 directory entry (namlen ≥ block size is accepted by the reader). Escalation: read-only primitive; 127 bytes of buffer-cache-adjacent KVA per call — KASLR/heap-layout aid, no write.

Fix

fix.diff (two hunks, both consumers):

1. chain.c: only run the data-block bcmp when name_len <= (size_t)chain->bytes (malformed entry never matches).
2. vnops.c readdir: skip the entry when namlen > 1 << (bref.data_off & HAMMER2_OFF_MASK_RADIX) (the radix is available in the frontend's copy of the bref).

A load-time rejection (chain->error = HAMMER2_ERROR_CHECK in hammer2_chain_load_data) was considered and rejected: the readdir xop feeds chains without checking chain->error and hammer2_xop_gdata() would then run on a NULL chain->data, trading the OOB read for a NULL-deref panic.

Fix validation (kernel #2, fix_run.log)

• Forged image: getdents returns cleanly (rc=0), the malformed 255-A entry is absent (no garbage tail), stat(A×255) → ENOENT, healthy entry longname_marker_check still lists (ino 1024) and stats.
• Control base image: unchanged — 255-A entry lists, stat succeeds (ino 1025) → no regression on legitimate long-name dirents.
• No panics during the whole validation run.