DF-0003 - devclass_alloc_unit() negative-unit heap out-of-bounds write

poc_negunit.c / poc_ctrl.c -- kld modules that drive the negative-unit heap OOB-write sink in devclass_alloc_unit() / devclass_add_device() (sys/kern/subr_bus.c).

The bug (memory-safety, CERTAIN -- reproduced on the audited kernel)

devclass_alloc_unit() only treats unit == -1 as a wildcard. Any other negative unit (e.g. -2) enters the "wired unit" branch but skips the existing-device check (unit >= 0, subr_bus.c:1073) and the table-extension check (unit >= dc->maxunit, subr_bus.c:1094), so it returns success with the negative unit. devclass_add_device() then executes

dc->devices[dev->unit] = dev;     // sys/kern/subr_bus.c:1144

an 8-byte pointer write at a NEGATIVE index into the kmalloc'd dc->devices array. device_set_unit() has a matching OOB read at subr_bus.c:2172.

Reproduction (VERIFIED)

A kld module that calls device_add_child(root_bus, "df3neg", -2):

• Control (poc_ctrl.ko, unit=0) loads cleanly and prints DF0003-CTRL: unit=0 -> OK (child=0xfffff800...). Guest stays up.
• Trigger (poc_negunit.ko, unit=-2) panics the kernel immediately:

Fatal trap 12: page fault while in kernel mode fault virtual address = 0xfffffffffffffff0 fault code = supervisor write data, page not present Stopped at devclass_add_device+0xf6: movq %r14,(%rdx,%rax,1)

addr2line -e /boot/kernel/kernel 0xffffffff8068a946 -> sys/kern/subr_bus.c:1144 (the exact sink line).

The fault address 0xfffffffffffffff0 = (device_t*)NULL + (-2) = 0 + (-2)*8, i.e. the negative-index write target. For the freshly-created devclass dc->devices == NULL, so the store hits an unmapped address and the kernel page-faults on the WRITE -- at the sink line.

The ONLY difference between the control and the trigger is the literal unit (0 vs -2), so the panic is caused specifically by the negative unit.

Reachability (the crux)

There is no unprivileged-userspace path to this sink in the default kernel. device_add_child / devclass_add_device / devclass_alloc_unit are internal newbus APIs; no syscall/ioctl invokes them. Auditing all 114 in-tree device_add_child* callers and the single device_set_unit caller (sio.c):

• 84 pass the -1 wildcard (the legitimate, handled case);
• the rest pass provably non-negative units -- PCI bus numbers (uint8_t secbus 0-255 in pci_pci.c:344, busno, bus), for(unit=0;;unit++) loop counters (ata-all.c, ata-pci.c), a monotonically-increasing freeunit/puc_find_free_unit() (starts >= 0 and only grows), and sio_pci_kludge_unit()'s unit that starts at 0 and only ++s.

So no in-tree driver computes a negative unit. The bug is therefore a real-but-latent memory-corruption defect: reachable today only by root (kldload, demonstrated here) or by any future/buggy driver that underflows a unit (signed subtraction, signed parse of a device-reported field, etc.). The fix is a one-line guard that converts the latent footgun into a hard EINVAL.

Build & run (on the DragonFly guest)

Building a kld requires the kernel source tree's headers; the guest ships without /usr/src, so setup_env.sh installs a headers-only subset first.

# one-time (root): install kernel headers + machine forwarders
sh setup_env.sh

# build both modules (as any user)
make SYSDIR=/usr/src/sys                      # -> poc_negunit.ko (trigger, -2)
make -f Makefile.ctrl SYSDIR=/usr/src/sys     # -> poc_ctrl.ko    (control, 0)

# run (root): control loads clean, trigger panics
sh run.sh

Files

DF-0003 -- VERDICT

Verdict: REPRODUCED (panic/OOB write) + FIX VALIDATED (memory-corruption sink confirmed at runtime on the unpatched master-DEV #0 kernel; single-fix kernel #1 built from fix.diff closes the bug — the trigger returns gracefully with no panic, deterministically across 3 runs).

Summary

devclass_alloc_unit() (sys/kern/subr_bus.c:1064-1125) only treats unit == -1 as a wildcard. Any other negative unit (e.g. -2) slips past every guard and is returned unchanged; devclass_add_device() then performs dc->devices[dev->unit] = dev (subr_bus.c:1144) -- an 8-byte pointer write at a negative array index. A tiny kld module calling device_add_child(root_bus, "df3neg", -2) drives this sink directly and panics the kernel at exactly subr_bus.c:1144. The control (unit=0) loads cleanly.

Mechanism (trigger -> primitive -> effect), cited path:line

1. Trigger: device_add_child(root_bus, "df3neg", -2) -> device_add_child_ordered -> make_device (subr_bus.c:1174). With name="df3neg", make_device calls devclass_find_internal(name, NULL, TRUE) which creates a fresh devclass with dc->devices = NULL; dc->maxunit = 0, then devclass_add_device(dc, dev).

2. Sink reach: devclass_add_device calls devclass_alloc_unit(dc, &dev->unit) (subr_bus.c:1139).

3. The missing guard (subr_bus.c:1064-1125): * int unit = *unitp; (:1067) -> unit = -2. * if (unit != -1) (:1072) -> TRUE (only -1 is the wildcard), enter the "wired unit" branch. * if (unit >= 0 && unit < dc->maxunit && dc->devices[unit] != NULL) (:1073) -> unit >= 0 is FALSE, the existing-device check is skipped. * if (unit >= dc->maxunit) (:1094) -> -2 >= 0 is FALSE, the table-extension block is skipped -- dc->devices is not grown and the negative unit is not caught. * *unitp = unit; return(0); (:1123-1124) -> returns success with dev->unit = -2.

4. OOB write (subr_bus.c:1144): back in devclass_add_device, dc->devices[dev->unit] = dev -> dc->devices[-2] = dev. With dc->devices == NULL this stores the 8-byte dev pointer at address 0 + (-2)*sizeof(device_t) = 0xfffffffffffffff0 (unmapped) -> supervisor WRITE page fault.

5. Effect: fatal trap 12, kernel panic, guest wedged in DDB. The faulting instruction is devclass_add_device+0xf6: movq %r14,(%rdx,%rax,1) (the indexed 8-byte store). addr2line resolves the IP to sys/kern/subr_bus.c:1144 -- the exact sink line.

device_set_unit() (subr_bus.c:2165-2184) has a matching OOB read at its bounds check if (unit < dc->maxunit && dc->devices[unit]) (:2172).

Reproduction evidence (unpatched #0 baseline)

Kernel: DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 (with-src base = full /usr/src + warm obj + unpatched audit kernel).

• Control (poc_ctrl.ko, unit=0) loaded cleanly: DF0003-CTRL: unit=0 -> OK (child=0xfffff801175bd1e0). Guest stays up.
• Trigger (poc_negunit.ko, unit=-2) panicked immediately. Serial console: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xfffffffffffffff0 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff8068b236 Stopped at devclass_add_device+0xf6: movq %r14,(%rdx,%rax,1) db> fault VA 0xfffffffffffffff0 = (device_t*)NULL + (-2) = 0 + (-2)*8, i.e. the negative-index write target. addr2line (prior verified run of identical source) -> sys/kern/subr_bus.c:1144. Guest went down (wedged in DDB).

The ONLY difference between control and trigger is the literal unit (0 vs -2), so the panic is caused specifically by the negative unit.

Reachability -- why this is "latent" but real

device_add_child / devclass_add_device / devclass_alloc_unit are internal newbus kernel APIs; no syscall or ioctl invokes them. The unit originates from bus-driver code (device_add_child*) or loader hints (root-controlled). Auditing the entire audited sys/ tree: 114 in-tree device_add_child(_ordered) callers and the single device_set_unit caller; 84 pass the literal -1 wildcard (the handled case), the rest pass provably non-negative units (PCI bus numbers, for(unit=0;;unit++) loop counters, monotonic freeunit/puc_find_free_unit(), sio_pci_kludge_unit()).

=> No in-tree path produces a unit < -1. The bug is a real-but-latent memory-corruption defect reachable today only by root (kldload, demonstrated) or by any future/buggy driver that underflows a unit. The fix is a one-line guard.

Exploit chain (memory-corruption class -- analysis)

• Primitive: dc->devices[N] = dev with attacker-selectable negative index N (the unit), writing the 8-byte kernel-heap pointer dev at offset N*8 before dc->devices.
• Triggering requirement: root (kldload) or a buggy driver. Not reachable from unprivileged userspace.
• This PoC's effect: deterministic panic (the easy fresh-devclass case has dc->devices == NULL, so the store faults immediately -- a clean DoS, not controllable corruption).
• Controllable-corruption variant (theoretical): target an existing devclass whose dc->devices is a real heap pointer, choose unit so dc->devices[N] lands on an adjacent slab object (function pointer / ucred * / refcount), and groom the heap. This needs root (kldload) and a kernel-ROP/ucred-forgery conversion, beyond what an unprivileged attacker can reach. Realistic impact ceiling: local DoS by root + latent corruption for a future driver bug. No uid0 chain pursued -- there is no unprivileged trigger to escalate from, and the root case is already game-over for the attacker.

Fix validation (Phase 8 -- single-fix kernel)

Fix (fix.diff, git-apply-able, supersedes the finding markdown's draft -- adds explicit EINVAL returns + comments): * devclass_alloc_unit entry: if (unit < -1) return (EINVAL); (sys/kern/subr_bus.c, now at line ~1073). * device_set_unit entry: if (unit < 0) return (EINVAL); (line ~2180).

Procedure: 1. vm.sh reset with-src -- clean source + #0 unpatched kernel. Re-confirmed baseline panic (above). 2. Applied fix.diff to /usr/src: patch -p1 -> both hunks succeeded (Hunk #1 succeeded at 1066, Hunk #2 succeeded at 2175). 3. Built single-fix kernel: make -j6 nativekernel KERNCONF=X86_64_GENERIC -> NK_DONE rc=0, no errors. Produced kernel.debug + kernel.stripped. 4. Installed: cp kernel.stripped /boot/kernel/kernel (the bare name the loader boots) + kernel.debug. sha256 5dc83dac...(#0) -> d7af6464...(#1). 5. Rebooted -> kern.version = DragonFly 6.5-DEVELOPMENT #1: Thu Jul 2 12:26:06 UTC 2026 (the #1 + new build ts confirm the rebuilt kernel). 6. Re-ran the SAME PoC on #1.

Before/after contrast (the decisive evidence):

Repeatability on #1: 3/3 runs (unload + reload) all return FAIL/NULL, guest up, 0 panics -- the fix is deterministic. device_add_child now returns NULL because devclass_alloc_unit rejects unit<-1 with EINVAL, so make_device fails before the dc->devices[dev->unit] = dev sink.

Fix verdict: FIXED. The single-fix kernel closes the OOB-write sink cleanly (panic -> graceful EINVAL).

PoC changes (vs. the filed PoC)

• Original poc_negunit.c included <sys/bus.h> (drags in platform/APIC headers) and used cc -DKERNEL (wrong macro -- the guard is _KERNEL). Forward-declared the newbus symbols and built via the standard bsd.kmod.mk. The hand-build (build.sh) is kept as a legacy path but the Makefile build is authoritative.
• Added poc_ctrl.c + Makefile.ctrl -- a unit=0 control that loads cleanly, so the trigger panic is provably caused by the negative unit and not by module plumbing.
• Added setup_env.sh, run.sh, env.txt, panic.txt, build.log, run.log, manifest.json, and fix.diff.
• This run: refreshed run.log/panic.txt with the #0 baseline signature from today's build; regenerated fix.diff with clean git-format headers (the old one had a bogus index hash line) and verified git apply --check passes; added fix_build.log (full nativekernel output) and fix_run.log (patched-kernel before/after contrast).

Recommended fix

Reject negative units at the entry of devclass_alloc_unit (< -1) and device_set_unit (< 0). See fix.diff (git-apply-able, supersedes the finding markdown's proposal -- adds explicit EINVAL returns and comments; validated by building + booting a single-fix kernel that eliminates the panic).