DF-0070 PoC — elf_getnote heap OOB read via crafted checkpoint image

Status: REPRODUCED (kernel panic / local DoS). Verified on DragonFlyBSD master DEV v6.5.0.1712.g89e6a-DEVELOPMENT (build 2026-06-29, X86_64_GENERIC). See VERDICT.md for the full analysis.

What this proves

That elf_getnote (sys/kern/kern_checkpoint.c:313-352) advances a parse offset using an attacker-supplied n_namesz (read from the untrusted note buffer at :325, applied at :339) with no bounds check against the allocated buffer size notesz. A crafted checkpoint image with n_namesz = 0x10000000 causes the subsequent bcopy at :346 to read sizeof(prpsinfo_t)=120 bytes from KVM 256 MB past the kmalloc(880) note buffer allocated at :194. The bcopy (backed by memmove) hits unmapped memory and the kernel page-faults in kernel mode (Fatal trap 12) → panic (vm_object_hold_shared assertion obj != NULL).

Build

./build.sh            # cc -o df0070 df0070.c   (on a DragonFlyBSD guest)

Run

Default kern.ckptgroup=0 (wheel-only) — run as root.

./run.sh              # ./df0070 evil.ckpt panic  -- kernel PANICS
./run.sh leak         # ./df0070 evil.ckpt leak   -- silent slab-adjacent
                      #                              116-byte OOB; returns
                      #                              EINVAL, no panic

Expected result (panic mode)

[*] DF-0070 PoC: building evil.ckpt  (notesz=880, n_namesz=0x10000000, n_descsz=120, mode=panic)
[*] calling sys_checkpoint(CKPT_THAW, fd=3, pid=-1, retval=0) [syscall #467]...
<ssh dies -- guest in DDB>

# in dfbsd-qemu/boot.log:
panic: assertion "obj != NULL" failed in vm_object_hold_shared at /usr/src/sys/vm/vm_object.c:330
cpuid = 0
...
--- trap 000000000000000c, rip = ffffffff80bca038, ... ---
memmove() at memmove+0x28 0xffffffff80bca038
Debugger("panic")
db>

The page fault is in memmove+0x28 — that is the inner bcopy backing the descriptor copy at kern_checkpoint.c:346. Reproduced twice with byte-identical code offsets.

Expected result (leak mode)

The kernel silently performs a 116-byte slab-adjacent OOB read (no page fault — the read stays inside the 1024-byte slab chunk), then elf_loadnotes rejects the leaked garbage at the pr_version/pr_psinfosz validation (:292-301) and returns EINVAL. The OOB read is real but silent; control does not reach the strlcpy(p->p_comm, ...) at :306, so the leak is not observable in ps/sysctl.

How the sizes were derived

probe.c prints the actual kernel-side struct sizes:

sizeof(prpsinfo_t)   = 120
sizeof(prstatus_t)   = 248
sizeof(prfpregset_t) = 512
sizeof(Elf_Note)     = 12

So the nthreads formula at :185, (notesz - 120) / 760, yields 1 for notesz = 880 — inside the [1, CKPT_MAXTHREADS=256] gate at :188.

Notes

• n_descsz must equal the kernel struct size at the :340 check, so for the first (NT_PRPSINFO) call it is 120 (sizeof(prpsinfo_t)).
• strncmp("CORE", src+*off, n_namesz) at :335 stops at the '\0' in "CORE\0" within 5 bytes regardless of n_namesz, so a giant n_namesz does not stop the match — it only inflates the subsequent *off advance.
• The original (pre-verification) PoC assumed wrong struct sizes (PRPSINFO_SZ=128, PRSTATUS_SZ=504); those were corrected.
• CKPT_THAW requires membership in kern.ckptgroup (default 0 = wheel). With kern.ckptgroup=-1 any local user can trigger the panic.

Files

• df0070.c — the generator + inline trigger.
• probe.c — struct-size probe (used to derive notesz=880).
• build.sh, run.sh — exact reproduce commands.
• build.log, run.log, run.2.log, run.leak.log — full untrimmed logs.
• panic.txt — the panic signature excerpted from boot.log.
• env.txt — guest environment.
• fix.diff — git apply-able fix (thread srcsz/notesz into elf_getnote, bounds-check every access).
• VERDICT.md, manifest.json.

DF-0070 — VERDICT

Verdict: REPRODUCED (panic / kernel-mode page fault).

The heap-OOB read described in DF-0070 is real on the audited DragonFlyBSD master DEV kernel (6.5-DEVELOPMENT, build v6.5.0.1712.g89e6a-DEVELOPMENT of 2026-06-29, X86_64_GENERIC). A crafted ELF checkpoint image, restored with sys_checkpoint(CKPT_THAW, fd, -1, 0) (syscall 467), drives elf_getnote's descriptor bcopy 256 MB past the kmalloc(880) note buffer and panics the kernel with Fatal trap 12: page fault while in kernel mode inside memmove. Reproduced twice (once before, once after vm.sh reset) with byte-identical code offsets in the panic stack — only the KASLR frame addresses differ between boots.

Mechanism (every hop cited path:line)

1. sys_checkpoint(CKPT_THAW) (sys/kern/kern_checkpoint.c:751) → ckpt_thaw_proc (:218).
2. ckpt_thaw_proc reads the ELF header (elf_gethdr, :230), the program headers (elf_getphdrs, :236), then calls elf_getnotes(lp, fp, phdr->p_filesz) at :240 — notesz flows straight from attacker-controlled phdr[0].p_filesz with no validation.
3. elf_getnotes (:176) derives nthreads purely from notesz at :185 — (notesz - sizeof(prpsinfo_t)) / (sizeof(prstatus_t) + sizeof(prfpregset_t)). With the verified amd64 sizes (prpsinfo_t=120, prstatus_t=248, prfpregset_t=512) and notesz=880, nthreads = 1, passing the [1, CKPT_MAXTHREADS=256] gate at :188.
4. note = kmalloc(notesz=880, M_TEMP, M_WAITOK) at :194 allocates an 880-byte heap buffer; read_check(fp, note, 880) (:198) fills it from the file. elf_demarshalnotes(note, psinfo, status, fpregset, 1) is called at :200.
5. elf_demarshalnotes (:354) calls elf_getnote(src, &off, "CORE", NT_PRPSINFO, &psinfo, sizeof(prpsinfo_t)=120) (:363) with off=0.
6. elf_getnote (:313): - bcopy(src+0, &note, 12) (:325) reads our crafted header: n_namesz=0x10000000, n_descsz=120, n_type=NT_PRPSINFO(3). - *off = 12 (:329). Type matches (:330). - strncmp("CORE", src+12, 0x10000000) (:335) — strncmp stops at the embedded '\0' in "CORE\0" within 5 bytes, returns 0. No OOB here, because the literal "CORE\0" lives inside the buffer. - *off += roundup2(0x10000000, 8) = 0x10000000 (:339) → *off = 0x1000000c. There is no check that *off <= notesz. This is the bug. - n_descsz == descsz (120 == 120) at :340 passes. - desc=&psinfo is non-NULL, so bcopy(src + 0x1000000c, psinfo, 120) at :346 reads 120 bytes from KVM 256 MB past the 880-byte slab chunk.
7. The bcopy (backed by memmove on amd64) page-faults in kernel mode on the unmapped access; the fault handler reaches vm_object_hold_shared on an address with no backing vm_object and panics with the assertion obj != NULL (vm/vm_object.c:330).

Privilege / reachability

• sys_checkpoint is gated by kern.ckptgroup at :728. Default 0 = wheel-only. The PoC runs as root.
• The parsed data is untrusted in all configurations; an admin who sets kern.ckptgroup=-1 exposes the panic to any local user.
• Realistic impact: local DoS (kernel panic) from any principal in the configured ckptgroup (default: root/wheel). With the optional kern.ckptgroup=-1 setting it is an unprivileged local DoS.

Why the leak variant does not escalate to info-leak

We also exercised the slab-adjacent OOB (n_namesz = 880-12-8 = 860, *off lands at 876, bcopy reads 120 bytes ending at 996 — 116 bytes past the 880-byte buffer but inside the 1024-byte slab chunk, hence no page fault). The 120-byte OOB read happens silently, but elf_loadnotes validates the loaded structures at :292-301:

if (status->pr_version != PRSTATUS_VERSION ||        // 1
    status->pr_statussz != sizeof(prstatus_t) ||     // 248
    ...
    psinfo->pr_version != PRPSINFO_VERSION ||        // 1
    psinfo->pr_psinfosz != sizeof(prpsinfo_t))       // 120
    error = EINVAL;

Random slab content almost never satisfies these magic+size checks, so control never reaches the strlcpy(p->p_comm, psinfo->pr_fname, ...) at :306. The leak is real but silent — the dominant observable impact is the panic.

What changed in the PoC

The supplied PoC assumed the wrong struct sizes (PRPSINFO_SZ=128, PRSTATUS_SZ=504). On the running kernel the real sizes are prpsinfo_t=120, prstatus_t=248, prfpregset_t=512, so the nthreads formula yields (notesz-120)/760. The PoC was rewritten to: - compute notesz = 120 + 248 + 512 = 880 so nthreads == 1, - build the malicious ELF in-process (no host-side struct dependency), - invoke sys_checkpoint(CKPT_THAW, fd, -1, 0) directly via syscall(SYS_checkpoint=467, ...), - default to the panic variant (n_namesz=0x10000000) and accept an optional leak argument for the slab-adjacent variant.

Reproduce

./build.sh               # cc -o df0070 df0070.c
./run.sh                 # ./df0070 evil.ckpt panic  -- kernel panics
# optional:
./run.sh leak            # ./df0070 evil.ckpt leak   -- silent OOB, returns EINVAL

Run as root (default kern.ckptgroup=0).

Fix

See fix.diff. The fix threads the source-buffer size srcsz (the notesz that elf_getnotes already holds) through elf_demarshalnotes into elf_getnote, and validates every access before touching memory: - *off + sizeof(note) <= srcsz before the header bcopy (:325), - note.n_namesz is sane (≤ 32, the longest legitimate ELF note name) and *off + roundup2(n_namesz, 8) <= srcsz before the strncmp and the advance at :339, - *off + roundup2(n_descsz, 8) <= srcsz before the descriptor bcopy at :346.

This matches the spirit of the finding markdown's proposal but adds an explicit n_namesz > 32 cap (defence-in-depth — strncmp is bounded by the null byte so an attacker cannot read past the buffer that way, but a multi-megabyte n_namesz is never legitimate in an ELF core note and is rejected outright). The nthreads over-count at :185 is left unchanged: once elf_getnote rejects *off > notesz, the surplus iterations in elf_demarshalnotes loop bail cleanly with EINVAL and the over-sized status[]/fpregset[] arrays are simply freed unused — no security consequence.

Fix VALIDATION (Phase 8 — built + booted single-fix kernel)

The fix was validated end-to-end on a single-fix kernel built from the audited /usr/src, not just git apply --check.

Baseline (unpatched #0, build Thu Jul 2 06:02:54 UTC 2026): ./df0070 evil.ckpt (panic mode, n_namesz=0x10000000) → ssh never returned; guest in DDB. vm.sh status ⇒ down. boot.log:

panic: assertion "obj != NULL" failed in vm_object_hold_shared at /usr/src/sys/vm/vm_object.c:330
--- trap 000000000000000c, rip = ffffffff80bca928, rsp = fffff80117251750, rbp = fffff801172517b8 ---
memmove() at memmove+0x28 0xffffffff80bca928
Debugger("panic")
db>

trap 0xc = kernel-mode page fault; memmove+0x28 is the bcopy backing the OOB descriptor read at kern_checkpoint.c:346. The bug reproduces on the unpatched baseline. (baseline_panic.txt.)

Build: cd /usr/src && patch -p1 < /root/fix.diff applied cleanly (7/7 hunks); make -j6 nativekernel KERNCONF=X86_64_GENERIC → === NK_DONE rc=0 ===. (fix_build.log, full untrimmed, 35598 lines.)

Install + reboot: copied the freshly-stripped kernel to the bare /boot/kernel/kernel the DragonFly loader boots, then vm.sh down && vm.sh up:

DragonFly 6.5-DEVELOPMENT #1: Thu Jul  2 15:29:19 UTC 2026
sha256(kernel) = 65ae8b9ec68b224ec90a7e4044aa869b7bf26e3604b42d3fd436c15638fb5ba3

#1 build stamp confirms the swap took.

Patched run (panic mode, ×3 determinism + leak mode): all return gracefully, guest stays up, zero panic lines in boot.log:

[*] calling sys_checkpoint(CKPT_THAW, fd=3, pid=-1, retval=0) [syscall #467]...
[!] sys_checkpoint returned -1, errno=22 (Invalid argument)
RUN_EXIT=1
guest status: up   (3/3 panic runs + leak run)

The new bounds checks reject the malformed note before any OOB access: - panic mode (n_namesz=0x10000000) trips note.n_namesz > 32 → EINVAL, - leak mode (n_namesz=860, namesz_pad=864): the name advance passes, but the next note's descsz_pad=120 > srcsz - *off (880-876=4) → EINVAL, stopping the descriptor OOB read at :346.

Fix verdict: VALIDATED. The previously-fatal panic on the unpatched #0 kernel is gone on the single-fix #1 kernel; CKPT_THAW now fails gracefully with EINVAL and the guest is fully responsive. Deterministic over 3 panic-mode + 1 leak-mode runs. (fix_run.log.)