DF-0831 — PoC evidence pack

Heap overflow in udf_getfid() via a negative frag_size produced by 4-byte FID alignment overshoot. sys/vfs/udf/udf_vnops.c:605 alignment can advance ds->off up to 3 bytes past ds->size; the next call's fragmented-FID branch then computes frag_size = ds->size - ds->off (negative), the signed guard at :544 (frag_size >= bsize) is bypassed, and bcopy(..., frag_size) at :555 sign-extends int(-3) to size_t(0xFFFFFFFFFFFFFFFD) → catastrophic kernel heap write → page fault → panic.

Files

How to reproduce

The image must be generated on a host with python3 (the guest has none); the harness builds on either. run.sh runs on the DragonFly guest as root (the readdir trigger itself is unprivileged).

# host
./build.sh                                   # -> df0831.udf, harness
scp df0831.udf run.sh dfbsd:/root/poc/DF-0831/

# guest (DragonFly 6.5-DEVELOPMENT #0 GENERIC)
sh /root/poc/DF-0831/run.sh                  # -> kernel panic (memmove+0x24f)

Expected (bug present): kernel page-fault in memmove/bcopy called from udf_readdir; guest frozen at the db> prompt.

Expected (after fix.diff): ls /mnt returns the directory entries (., .., AB, X) with no panic.

Determinism

Reproduced 5× across 3 image revisions; the fault address varies per run (0xfffff800566b5ff9, 0xfffff80054ec5ff9, 0xfffff80118132000, 0xfffff80118274000, …), confirming a real unbounded read and not a fixed-address artifact.

DF-0831 — VERDICT

Status: REPRODUCED · Impact: panic (kernel heap OOB write, DoS) · Confidence: certain Fix: VALIDATED (single-line clamp; patched udf.ko survives the PoC cleanly)

The bug (root cause, line-by-line)

udf_getfid() in sys/vfs/udf/udf_vnops.c iterates File Identifier Descriptors (FIDs) of a UDF directory. The directory data is read one extent at a time into ds->data with ds->size = bytes available in the current extent, while ds->fsize = the directory's total inf_len (udf_vnops.c:673), which can span multiple extents.

The four lines that combine into a catastrophic heap write:

1. udf_vnops.c:605 — after a non-fragmented FID, the cursor is advanced with 4-byte alignment: c ds->off += (total_fid_size + 3) & ~0x03; When total_fid_size is not a multiple of 4, this rounds up by 1–3 bytes. The fragmentation guard at :539–:540 only requires ds->off + total_fid_size <= ds->size, so the aligned advance can push ds->off up to 3 bytes past ds->size.

2. udf_vnops.c:505 — the next call's end-of-directory test compares against ds->fsize, not ds->size: c if (ds->offset + ds->off >= ds->fsize) { ... return NULL; } For a multi-extent directory fsize > size, so a 1–3 byte overshoot does not terminate the loop. (A single-extent directory has fsize == size, which is why the bug needs ≥2 extents — see "Reachability".)

3. udf_vnops.c:543 — the (now mis-aligned) cursor enters the fragmented-FID branch and computes the fragment size: c frag_size = ds->size - ds->off; /* int : 81 - 84 == -3 */

4. udf_vnops.c:544 and :555 — the guard is a signed compare and the length is passed to bcopy whose third argument is size_t: c if (frag_size >= ds->udfmp->bsize) { ... } /* -3 >= 2048 -> FALSE -> BYPASS */ ... ds->buf = kmalloc(ds->udfmp->bsize, M_UDFFID, M_WAITOK | M_ZERO); bcopy(fid, ds->buf, frag_size); /* int(-3) -> size_t 0xFFFFFFFFFFFFFFFD */ The negative int sign-extends to ≈ 16 EB on 64-bit → an unbounded kernel heap write out of the freshly kmalloc(2048)'d ds->buf.

Reproduction (default GENERIC kernel, INVARIANTS ON)

A minimal but valid UDF image (craft_img.py) is built whose root directory has two extents:

With ds->size = 81 for extent 0: * FID_B passes the guard (40 + 41 == 81 <= 81), takes the non-fragmented branch, and :605 advances ds->off to 40 + 44 == 84 → overshoots ds->size by 3. * Next udf_getfid() call: :505 0 + 84 < 121 → not end-of-dir; :539 84 + 38 > 81 → fragmented branch; frag_size = 81 - 84 = -3; signed guard bypassed; bcopy(..., (size_t)-3) → page fault.

Trigger (root mounts the image; the readdir is unprivileged):

vnconfig -c vn0 df0831.udf
mount_udf -o ro /dev/vn0 /mnt
su maxx -c 'ls /mnt'      # -> kernel panic

Panic (5 reproductions, varying fault address — a real unbounded read):

panic: vm_fault: fault on stack guard, addr: 0xfffff80118274000
--- trap 000000000000000c, rip = ffffffff80bcab4f ---
memmove() at memmove+0x24f 0xffffffff80bcab4f          <- bcopy() backend
udf_readdir() at udf_readdir+0x138 0xffffffff82602298  <- caller

memmove+0x24f is repe movsq (%rsi),%es:(%rdi) — the bulk copy faulting on the source running off the end because the length is 0xFFFFFFFFFFFFFFFD.

Deterministic harness

harness.c transcribes the udf_getfid() arithmetic verbatim (the :605 alignment, the :543 negative frag_size, the :544 signed-guard bypass, the :555 int→size_t bcopy) with a poison allocator (one RW page followed by a PROT_NONE guard page). Output:

udf_getfid() call #2: aligned advance -> ds->off=84  *** OVERSHOOT by 3 (ds->size=81) ***
udf_getfid() call #3: frag_size(int) = -3
                     (size_t)frag_size = 0xfffffffffffffffd  (18446744073709551613 bytes)
                     signed check `frag_size>=bsize` -> BYPASSED
bcopy overrun into poison region -> FAULT caught (crossed the buffer boundary)

Exploit-chain assessment (why impact = panic, not uid0)

The primitive is a genuine heap OOB write (CWE-787), but its magnitude is the whole story: the bad length is always size_t(-1|-2|-3) ≈ 16 EB — it is not attacker-tunable to a small, controlled value (frag_size is fixed by the alignment overshoot of at most 3 bytes). Consequently:

• The repe movsq copy loop in bcopy/memmove runs straight off the end of the kmalloc(2048) destination (and the bp-buffer source) and page-faults on the first unmapped page — within a page or two — before any code path can dereference a corrupted victim object. The fault is in the copy itself, not in a later consumer, so there is no window in which a corrupted function-pointer / ucred * / refcount gets called or dereferenced.
• There is no way through this bug to produce a precise, bounded overwrite of a chosen slab object; the sign-extended length is intrinsically maximal, so slab grooming cannot convert it into control-flow hijack on the default GENERIC kernel (and the same page-fault happens on an INVARIANTS-OFF kernel too — INVARIANTS/KASSERT are not even reached).

This is a valid stop for the escalation phase: the primitive's nature (maximal-length, immediately-faulting copy) cannot be shaped into a controlled write that survives long enough to be leveraged. The realistic impact ceiling is therefore local kernel panic / DoS from a crafted filesystem image (mount requires root; the triggering readdir is unprivileged — the standard "admin mounted attacker media" model). No uid=0 is claimed.

Reachability note (single-extent dirs are safe)

The bug requires a multi-extent directory so that the :505 fsize-based end-of-dir test does not catch the 1–3 byte overshoot (a single extent has fsize == ds->size, so :505 terminates immediately). mkudffs-style images typically produce single-extent directories, which is why this needs a crafted image — but multi-extent directories are entirely legal UDF (large dirs, certain writer layouts), so the path is genuinely reachable, not dead code.

The fix (fix.diff)

Minimal, targeted at the root cause — clamp the negative frag_size to 0 before it reaches the int→size_t bcopy length promotion. When frag_size == 0 the subsequent code reads the entire FID from the next extent (:566–:593), which is the semantically-correct behavior for a FID that begins in the next extent (the overshoot bytes were the previous FID's alignment padding):

frag_size = ds->size - ds->off;
if (frag_size < 0)        /* <- added: alignment overshoot; FID is in next extent */
    frag_size = 0;
if (frag_size >= ds->udfmp->bsize) { ... }

Fix validation (Phase 8)

fix.diff applied to /usr/src, udf.ko rebuilt with make SYSDIR=/usr/src/sys KERNCONF=X86_64_GENERIC, swapped into /boot/kernel/udf.ko, kldloaded, and the same PoC re-run:

git apply --check passes; the module compiles clean (rc=0); before/after is a clean panic→no-panic. fix_status: fixed.

(ls -l reports "Cannot allocate memory" when stat-ing the AB/X entries because those file inodes (lb_num 4/5) have no File Entry in this minimal image — udf_vget returns ENOMEM. This is a property of the tiny test image, not the readdir path, which returns cleanly.)