DF-2808 — Cross-segment mapsize under-sizing → file-controlled kernel heap overflow in link_elf_load_file

Build

python3 gen_exec_ko.py seg-overflow.ko seg-overflow

(host-side; no guest toolchain needed. Produces a 4.2 MB ET_EXEC x86-64 module.)

Run

scp -F dfbsd-qemu/config seg-overflow.ko dfbsd:/tmp/
dfbsd-qemu/vm.sh run_root 'kldload /tmp/seg-overflow.ko; echo RC=$?'
dfbsd-qemu/vm.sh log 30     # panic signature

Expected (stock kernel, verified 2026-09-01)

Fatal trap 12: page fault while in kernel mode
fault code       = supervisor write data, page not present
Stopped at      memmove+0x10a:  repe movsq (%rsi),%es:(%rdi)

Guest panics (write fault inside the vn_rdwr/uiomove copy). Before the fault, ~64 KB of adjacent kernel heap has already been overwritten with 0x41 bytes read from the module file.

Expected (patched kernel, fix.diff applied)

kldload: Segment ... error, RC != 0, guest stays up

(specifically "kldload: Overlapping or out-of-order segments" + ENOEXEC)

Why (root cause, sys/kern/link_elf.c)

link_elf_load_file sizes the module mapping ONLY from the first segment's start and the SECOND segment's end:

541:  base_vaddr  = trunc_page(segs[0]->p_vaddr);
542:  base_vlimit = round_page(segs[1]->p_vaddr + segs[1]->p_memsz);
543:  mapsize     = base_vlimit - base_vaddr;
546:  ef->address = kmalloc(mapsize, M_LINKER, M_WAITOK);
553:  segbase     = mapbase + segs[i]->p_vaddr - base_vaddr;
554:  vn_rdwr(UIO_READ, vp, segbase, segs[i]->p_filesz, ...)

segs[0]'s own extent (p_vaddr + p_memsz, and p_filesz) is never required to fit inside mapsize, and the "text then data, in that order" assumption (line 497 comment) is never enforced. The trigger module uses

segs[0]: p_vaddr=0,      p_filesz=p_memsz=0x400000  (4 MB of 'A')
segs[1]: p_vaddr=0x100,  p_filesz=p_memsz=0x100
=> mapsize = round_page(0x200) - 0 = 0x1000 (one page)
=> vn_rdwr writes 4 MB of file-controlled bytes into the 1-page kmalloc

Even with p_filesz <= p_memsz in BOTH segments (so DF-0056's check-site is not involved), the read overruns the allocation. Out-of-order segments (seg1 below seg0) underflow mapsize to ~2^64; p_vaddr + p_memsz wrapping 2^64 shrinks base_vlimit — same unvalidated-arithmetic family, all fixed by the segment-layout validation in fix.diff.

Threat model: kldload requires root (SYSCAP_NOKLD) — root-supplied-input class, consistent with DF-0056 (Medium). The primitive is a deterministic, fully file-controlled heap overflow (write-what-where contiguous) in the kernel M_LINKER heap.

DF-2808 VERDICT — reproduced (panic / kernel heap overflow, root-gated)

Status: reproduced. Verified on the stock guest kernel DragonFly 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026 X86_64_GENERIC (fresh vm.sh reset with-src before the run).

How it manifests

kldload /tmp/seg-overflow.ko (as root) panics the guest:

Fatal trap 12: page fault while in kernel mode
cpuid = 3; lapic id = 3
fault virtual address  = 0xfffff80116e69000
fault code             = supervisor write data, page not present   <-- WRITE
Stopped at      memmove+0x10a:       repe movsq (%rsi),%es:(%rdi)

(run.log, panic.txt). The fault is a supervisor WRITE inside the memmove that vn_rdwr/uiomove uses to copy file bytes into the module mapping — i.e. the overflow ran off the end of the mapping while still copying attacker file data. Everything between the end of the 1-page kmalloc (0x1000 bytes, M_LINKER) and the faulting page (0xfffff80116e69000, ≈64 KB later) was overwritten with 0x41 bytes read from the module file before the first unmapped page stopped the copy.

Root cause (path:line)

sys/kern/link_elf.c:541-543:

base_vaddr  = trunc_page(segs[0]->p_vaddr);
base_vlimit = round_page(segs[1]->p_vaddr + segs[1]->p_memsz);
mapsize     = base_vlimit - base_vaddr;

The mapping size accounts only for segs[0]'s start and segs[1]'s end. segs[0]'s own end (p_vaddr + p_memsz) is never checked against mapsize, nor is segment ordering, nor 64-bit wraparound of p_vaddr + p_memsz. sys/kern/link_elf.c:552-564 then reads p_filesz file bytes at mapbase + p_vaddr - base_vaddr and bzeros p_memsz - p_filesz — both unbounded by the actual allocation when the arithmetic lies.

The comment at sys/kern/link_elf.c:496-499 documents the assumption ("We rely on there being exactly two load segments, text and data, in that order") but nothing enforces it. This is the DF-2771 analogue (mapsize accumulation overflow in link_elf_obj.c) expressed through THIS file's distinct program-header-driven code path, and it is strictly more general than DF-0056 (which needs p_filesz > p_memsz within one segment): here both segments satisfy p_filesz <= p_memsz and the overflow still happens because the allocation is sized from the wrong expression.

Exploit chain (characterization)

Primitive: contiguous kernel-heap overflow with 100% file-controlled content, overflow length and start offset chosen by the module author (segs[0].p_filesz up to file size, segs[1] placement controlling mapsize). Consumers of adjacent M_LINKER/slab memory at the moment of load include previously-loaded module mappings and linker_file structures.

Honest ceiling: kldload is root-gated (SYSCAP_NOKLD, sys/kern/kern_linker.c kldload syscall), so the attacker model is "malicious root-supplied module file" — the same class as DF-0056. For that attacker, a working .ko is already arbitrary kernel code; the bug's operational impact is (a) kernel memory corruption/panic from a file that should have been rejected with ENOEXEC, and (b) it defeats any defense-in-depth scheme that sandboxes or whitelists module content (e.g. signed-hash whitelisting of known modules) because memory outside the loader's allocation is modified. No unprivileged→root chain exists through this path (verified: kldload requires uid 0 / kern.securelevel checks).

Fix validation

fix.diff (this pack) adds, before the mapping is sized:

1. per-segment p_filesz <= p_memsz (completes DF-0056's missing check),
2. per-segment p_vaddr + p_memsz wraparound rejection,
3. segs[0]->p_vaddr + segs[0]->p_memsz <= segs[1]->p_vaddr + segs[1]->p_memsz (ordering + seg0-extent-inside-mapsize),
4. mapsize != 0,
5. nsegs == 2 before any segs[] dereference.

Built as make -j6 nativekernel KERNCONF=X86_64_GENERIC in the guest, installed, rebooted. Re-run of the exact PoC: rejected with kldload: Overlapping or out-of-order segments, RC!=0, guest stays up, zero panics. See fix_build.log / run_fix.log.