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 (memory-corruption sink confirmed at runtime on the audited master-DEV kernel; impact = kernel panic / DoS, root-gated; latent for any future buggy driver that underflows a unit).

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 (proven by addr2line). 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 (subr_bus.c:1247) -> make_device (subr_bus.c:1174). With name="df3neg", make_device calls devclass_find_internal(name, NULL, TRUE) (subr_bus.c:1183) which creates a fresh devclass with dc->devices = NULL; dc->maxunit = 0 (subr_bus.c:759-760), then devclass_add_device(dc, dev) (subr_bus.c:1211).

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), at IP 0xffffffff8068a946, which addr2line resolves 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) -- a negative unit makes unit < dc->maxunit TRUE, so dc->devices[unit] reads out of bounds; if it reads NULL, execution proceeds to dev->unit = unit; devclass_add_device(dc, dev) (:2177-2178), hitting the same write sink. No in-tree caller exercises this.

Evidence

• run.log -- decisive run: control prints DF0003-CTRL: unit=0 -> OK (child=0xfffff80065c20ea0), guest stays up; trigger panics. Boot.log (serial console) delta shows: fault virtual address = 0xfffffffffffffff0 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff8068a946 Stopped at devclass_add_device+0xf6: movq %r14,(%rdx,%rax,1)
• panic.txt -- crash signature + addr2line proof that IP 0xffffffff8068a946 = subr_bus.c:1144.
• build.log -- full successful bsd.kmod.mk build.

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 (sys/dev/serial/sio/sio.c:407).
• 84 callers pass the literal -1 wildcard (the handled case).
• The rest pass provably non-negative units:
• sys/bus/pci/pci_pci.c:344 -- sc->secbus, a uint8_t PCI secondary bus number (0-255, pcib_private.h:53).
• sys/dev/disk/nata/ata-pci.c:233/242 -- for(unit=0;...) loop counter; freeunit = 2; ... freeunit++ (monotonic).
• sys/dev/acpica/acpi_pcib.c:161, sys/bus/pci/x86_64/pci_bus.c:474 -- busno / bus (PCI bus numbers).
• sys/dev/misc/puc/puc.c:327 -- puc_find_free_unit() (>= 0 by definition).
• sio.c sio_pci_kludge_unit() -- unit starts at 0 and only ++s.

=> No in-tree path produces a unit < -1. The bug is therefore a real-but-latent memory-corruption defect reachable today only by root (kldload, demonstrated) or by any future/buggy driver that underflows a unit (signed subtraction underflow, signed parse of a device-reported field, etc.). 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 (e.g. reuse a known driver's devclass), choose unit so dc->devices[N] lands on an adjacent slab object (function pointer / ucred * / refcount), and groom the heap. This would need root (kldload) and a kernel-ROP/ucred-forgery conversion, which is beyond what an unprivileged attacker can reach. Given the root-only trigger, the realistic impact ceiling is local DoS by root + latent corruption for a future driver bug. No uid0 chain was pursued -- there is no unprivileged trigger to escalate from, and the root case is already game-over for the attacker.

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 (correct kernel CFLAGS, machine forwarders). 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 (install kernel headers + forwarders on a guest that lacks /usr/src), run.sh, env.txt, panic.txt, build.log, run.log, manifest.json, and fix.diff.

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 draft -- adds an explicit EINVAL return and comments).