DF-0024 — PoC

kldload_overflow.c — root-only heap overflow in linker_search_path().

The bug

linker_search_path (sys/kern/kern_linker.c:1458) kmalloc(MAXPATHLEN=1024) then :1476 strcpy(result + prefix_len, name) + :1480 ext with no bounds check. A 1023-byte bare module name (the max copyinstr allows at :798) with the default linker_path "/boot/kernel" (13 prefix) + ".ko" (3) + NUL = 1040 into a 1024-byte buffer → ~16-byte heap overflow into adjacent M_LINKER objects.

Reachability

Gated behind SYSCAP_NOKLD (sys_kldload :794) — root only. Root can already kldload an arbitrary .ko for kernel code execution, so this is a defense-in-depth / local-DoS finding, not a new privilege.

Build & run (root, disposable VM)

cc -o kldload_overflow findings/poc/DF-0024/kldload_overflow.c
./kldload_overflow

Expected output (bug present)

Kernel panic from heap corruption / slab assertion ("freed pointer ... was modified", malloc red-zone, etc.).

DF-0024 — VERDICT

Verdict: REPRODUCED (code-level; silent heap OOB write, root-only)

Impact: Heap OOB write (corruption) — root-only trigger; defense-in-depth / local-DoS class. The overflow is real (confirmed by line-by-line source trace and code-path reachability analysis) but silent on the default GENERIC kernel: DragonFlyBSD's slab allocator has no heap redzone, so a 16-byte overflow past a 1024-byte M_LINKER allocation into the adjacent slab chunk does not fault or panic. The PoC exercises the vulnerable path and the overflow IS written, but produces no userspace-observable crash.

Mechanism (trigger → primitive → effect)

1. Trigger: kldload("<1023-byte bare name>") (root-only, SYSCAP_NOKLD gate at sys/kern/kern_linker.c:794). copyinstr at :798 accepts up to MAXPATHLEN-1 = 1023 bytes. A name with no / and no . takes the bare-module branch at :809-811 (modname = file).

2. Path to vulnerable function: sys_kldload:815 → linker_load_module(NULL, modname, …) (:1536) → linker_search_path(modname) (:1413).

3. Primitive: In linker_search_path, the name has no /, so it falls through both early returns (:1427, :1431) to the "traverse the linker path" section at :1458: c buf = kmalloc(MAXPATHLEN /* 1024 */, M_LINKER, M_WAITOK); /* :1458 */ ... name_len = strlen(name); /* 1023 */ ... prefix_len = 12; /* "/boot/kernel" */ sep = 1; /* no trailing '/' */ strncpy(result, cp, prefix_len); /* 12 bytes */ result[prefix_len++] = '/'; /* offset 12, prefix_len→13 */ strcpy(result + prefix_len, name); /* :1476 — writes 1024 bytes (name+NUL) at offset 13 */ ... result_len = strlen(result); /* 1036 */ strcpy(result + result_len, ".ko"); /* :1480 — writes 4 more bytes at offset 1036 */ With prefix_len=13 and name = 1023 bytes + NUL = 1024 bytes, strcpy at :1476 writes offsets 13..1036 — overflowing the 1024-byte buffer by 13 bytes (offsets 1024..1036). The :1480 ext strcpy adds 4 more bytes at offsets 1036..1039. Total overflow: ~16 bytes into the adjacent M_LINKER slab chunk.

4. Effect: Silent heap corruption. The overflowed path string (/boot/kernel/AAA…AAA.ko) is passed to nlookup_init/vn_open which returns ENOENT (file doesn't exist). The buffer is then kfree'd. The adjacent slab chunk's first 16 bytes are corrupted, but the slab allocator does not detect this (no redzone; INVARIANTS only checks the allocation bitmap for double-alloc/free and poisons freed chunks with WEIRD_ADDR). The corruption may surface later as a UAF/double-free if the adjacent chunk is a live linker_file object whose refs/flags/userrefs fields are overwritten, but this is not reliably triggerable from the PoC.

Why no panic?

DragonFlyBSD's slab allocator (sys/kern/kern_slaballoc.c) has no heap redzone: - chunk_mark_allocated/chunk_mark_free (:1654/:1670) only check the allocation bitmap (double-alloc/double-free detection), not the chunk content. - WEIRD_ADDR (0xdeadc0de) poisoning (:1568-1571) only fills freed chunks — it detects UAF, not overflow into an allocated chunk. - The overflow goes into the adjacent slab chunk's data area, which may be allocated (corrupts a live object silently) or free (corrupts the WEIRD_ADDR pattern, which is never checked on re-alloc).

Confirmed by running the PoC 50× in a tight loop on the unpatched #0 kernel: no panic, no kernel log, guest stays up.

Exploit chain

Not applicable for privilege escalation. The trigger is root-only (SYSCAP_NOKLD): root can already kldload an arbitrary .ko for direct kernel code execution, so there is no privilege boundary to cross. This is a defense-in-depth / local-DoS finding, consistent with the Low severity rating. Under KLD-signature enforcement or a capsicum-restricted root with only the KLD capability, the heap corruption primitive would become meaningful (potential UAF via corrupting adjacent linker_file metadata), but that is not the default threat model.

PoC changes

• Fixed nested C comment in kldload_overflow.c:6 — /* 1024 */ inside the block comment prematurely closed the outer /*, causing a compile failure. Replaced with (=1024).

Fix validation (Phase 8)

fix.diff adds two layers of defense: 1. Root cause (linker_search_path, :1470-1494): compute ext_max once, then skip any path component whose assembly prefix_len + sep + name_len + ext_max + 1 > MAXPATHLEN before the strcpy. 2. Input validation + observable marker (sys_kldload, :812-823): reject bare module names longer than MAXPATHLEN - 32 with ENAMETOOLONG before reaching linker_search_path.

Before/after (decisive): - Unpatched #0 (6.5-DEVELOPMENT #0, Thu Jul 2 06:02:54 UTC 2026): kldload("AAA…AAA") → ENOENT ("No such file or directory") — overflow happens silently. - Patched #1 (6.5-DEVELOPMENT #1, Sun Jul 12 18:47:23 UTC 2026, sha256 5e48e21e…): kldload("AAA…AAA") → ENAMETOOLONG ("File name too long") — length check fires before the overflow. 3/3 deterministic.

Regression check: legitimate short module name (kldload /nonexistent_module) still returns ENOENT on the patched kernel — no regression.

Fix status: FIXED.