DF-2771 — mapsize 64-bit wrap in link_elf_obj_load_file → undersized KVA mapping → wild bzero past its end

Build (host)

python3 gen_module.py df2771.ko mapsize-wrap

(no guest build needed — the trigger is a hand-crafted 554-byte ET_REL object)

Run (guest, root — kldload is SYSCAP_NOKLD-gated)

scp -F dfbsd-qemu/config df2771.ko dfbsd:/tmp/
dfbsd-qemu/vm.sh run_root 'kldload /tmp/df2771.ko'

Expected — stock kernel (baseline, reproduced)

Serial console (see panic.txt):

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xffffffff82602000
fault code = supervisor write data, page not present
Stopped at memset+0xd5: repe stosq

The two NOBITS sections declare sh_size 0xFFFFFFFFFFFFF000 and 0x2000 (sum ≡ 0x1010 mod 2^64), so the mapsize accumulator wraps to 0x1010 → a 2-page mapping is created, then bzero(mapbase+16, 2^64-0x1000) (link_elf_obj.c:760) zero-fills forward until the first unmapped page past the mapping → panic.

Expected — patched kernel (fix.diff applied, kernel #1 Sep 1 2026)

kldload: /tmp/df2771.ko: section too large

RC=1, no panic, guest stays up (ALL-SURVIVED).

Threat model

kldload(2) is root-only (caps_priv_check_self(SYSCAP_NOKLD), kern_linker.c:792) and blocked at securelevel>0 — this is root-supplied-input / verified-boot class (malformed or substituted module), consistent with the Low-severity calibration of DF-0040/0041/0042.

DF-2771 — VERDICT

REPRODUCED (panic / uncontrolled kernel-memory write, root-gated).

Root cause (sys/kern/link_elf_obj.c)

The sizing loop at sys/kern/link_elf_obj.c:621-633 accumulates every SHT_PROGBITS/SHT_NOBITS sh_size into a plain size_t mapsize with no overflow check and no per-section cap:

621:    for (i = 0; i < hdr->e_shnum; i++) {
622:        if (shdr[i].sh_size == 0)
623:            continue;
624:        switch (shdr[i].sh_type) {
625:        case SHT_PROGBITS:
626:        case SHT_NOBITS:
627:            alignmask = shdr[i].sh_addralign - 1;
628:            mapsize += alignmask;
629:            mapsize &= ~alignmask;
630:            mapsize += shdr[i].sh_size;      /* <-- u64 wrap */

sh_size is an attacker-chosen Elf64_Xword taken verbatim from the module's section headers. With e_shnum ≤ 65535 sections, any total ≥ 2^64 requires at least one section ≥ 2^48, so a wrap necessarily leaves a monster section whose load-side length is used raw:

• :640-641 vm_object_allocate(..., round_page(mapsize) >> PAGE_SHIFT) — sized from the wrapped total (0x1010 → 2 pages);
• :663-667 vm_map_find(kernel_map, ..., round_page(mapsize), ...) — 2-page wired mapping;
• :733-760 per-section load: NOBITS → bzero(ef->progtab[pb].addr, shdr[i].sh_size) with the raw 2^64-0x1000 length.

The consistency panic at :812-815 cannot save this — the wild bzero runs first (and the placement arithmetic itself stays self-consistent under wrap).

Sibling unchecked consumers of the same field on the same path: :734-738 (vn_rdwr into the mapping for PROGBITS — file-backed, so not practical past EOF) and the alignment truncation alignmask = sh_addralign - 1 (int), which was analyzed and found to either stay within the mapping or land on mapbase == 0 → caught by the NULL check at :727-730 (ENOSPC).

Reproduction (baseline, stock kernel)

Guest: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 … X86_64_GENERIC x86_64, securelevel -1. Trigger module built by gen_module.py df2771.ko mapsize-wrap (host python3; no guest toolchain needed): 7 sections — NULL, .text(16B PROGBITS), .symtab(1 sym), .strtab, .shstrtab, NOBITS sh_size=0xFFFFFFFFFFFFF000 align=1, NOBITS sh_size=0x2000 align=1.

kldload /tmp/df2771.ko → ssh session hangs; serial console:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xffffffff82602000     <- first page past the 2-page mapping
fault code = supervisor write data, page not present
Stopped at memset+0xd5: repe stosq             <- the wild bzero

(panic.txt, full excerpt of the decisive run.)

Primitive characterization (why impact stops at panic)

The write is a zero-fill of unbounded length starting inside the module's own 2-page mapping, running forward until the first unmapped page. The attacker controls start (mapbase+section offsets, sub-page granularity) but neither the written value (always 0x00) nor a stop point: the kernel_map region above a freshly-allocated module mapping is unmapped in practice (proven by the immediate fault at the mapping edge, VA 0xffffffff82602000), so the deterministic outcome is a fatal supervisor-write page fault. Had a live mapping been adjacent above the module, its contents would be zeroed first (blind corruption), but the run still terminates in the same fault — there is no route from this primitive to controlled execution, and the triggering user is already root (kldload is SYSCAP_NOKLD-gated, kern_linker.c:792, and blocked at securelevel>0, kern_linker.c:789). No leak and no unprivileged reach — uid0 escalation is out of scope for this class (the loader input is root-supplied), so the run is honestly closed at impact=panic.

Fix validation

fix.diff (this pack; identical in DF-2771/2772/2773 packs — one combined patch): adds LINKER_MAX_SECSIZE (1LL<<44) cap checked in the sizing loop → ENOEXEC "section too large" before any allocation. With e_shnum ≤ 65535 the accumulator can then never exceed ~2^60.3, so wrap is impossible.

Applied to the guest's /usr/src copy (sys/ tree untouched in the repo), make -j6 nativekernel KERNCONF=X86_64_GENERIC (build.log, 37903 lines, -Werror clean, --- link_elf_obj.o ---), make installkernel, reboot into #1: Tue Sep 1 01:04:57 UTC 2026. Re-run of the exact same PoC:

kldload: /tmp/df2771.ko: section too large    (dmesg)
RC=1, guest stays up, 0 panics in console log

Baseline panic gone on the patched kernel → fix_status=fixed.

Negative space checked on the same path (no findings)

• nbytes = e_shnum * e_shentsize (:497): e_shentsize==64 is enforced before kmalloc; max 65535*64 fits int.
• Huge-but-unwrapped mapsize: fails cleanly in vm_map_find → ENOMEM.
• sh_addralign==0 / 2^32 truncation: mapbase clamps to 0 → caught by the NULL-addr check at :727-730 (ENOSPC).
• vm_object refcount handling across wiring failure/unload (:646-673, :900-910): correct.