DF-0074 PoC — DIOCGSLICEINFO heap overflow via crafted GPT disk image

What this proves

The DIOCGSLICEINFO handler (sys/kern/subr_diskslice.c:557) bcopy()s dss_nslices-worth of struct diskslice (256 B each) into the ioctl data buffer, which mapped_ioctl sizes at sizeof(struct diskslices) = 4128 B (only MAX_SLICES = 16 slots). A GPT disk whose header advertises 128 entries makes the kernel set dss_nslices = BASE_SLICE + 128 = 130 (sys/kern/subr_diskgpt.c:175,222), so the bcopy writes 32 + 130*256 = 33312 bytes into the 4128-byte buffer — a deterministic 29184-byte (~28 KB) overrun of kernel heap on every call. With slab churn the overrun reliably surfaces as a kernel panic; the underlying memory corruption is weaponizable for local privilege escalation.

Verified on

DragonFly 6.5-DEVELOPMENT master DEV (v6.5.0.1712.g89e6a-DEVELOPMENT #1, X86_64_GENERIC). See VERDICT.md for the full narrative and env.txt for the guest environment.

Reproduce

# 1. On a host with python3: build the crafted GPT image (128 entries).
python3 build_gpt.py overflow.img

# 2. Copy the whole folder + overflow.img to the guest (as maxx).
#    scp -r . dfbsd-maxx:poc/DF-0074/

# 3. On the guest, build the triggers (as maxx).
sh ./build.sh                      # -> trigger, trigger_stress

# 4. Attach the image and fire the overflow (as root; see Reachability).
#    sh ./run.sh vn0
#
#    The single trigger prints "DIOCGSLICEINFO returned nslices=130"
#    (proof the oversized bcopy executed). The stress/flood section then
#    forces the slab corruption to surface. The panic is ASYNCHRONOUS and
#    may land a few seconds after the script returns; capture it from the
#    serial console log (dfbsd-qemu/boot.log on the QEMU host).

run.sh must run as root (or a principal in the operator group / a devfs class that exposes slice devices). On the default devfs ruleset, /dev/vn0* are root:operator crw-r----- and operator contains only root, so an unprivileged user gets EACCES.

Expected result (bug present)

• The trigger returns nslices=130 (the 28 KB heap overflow executes).
• The guest panics within the run (asynchronous, heap-layout dependent). Observed signatures on master DEV (all in panic.txt):
• panic: slaballoc: corrupted zone in _kmalloc <- fork1
• Fatal trap 12 ... slab_cleanup+0x1c9 (NULL deref, idle reclaimer)
• panic: ... hammer2_chain_create preceded by dscheck(vbd0s1d): slice too large (the overrun corrupted the root disk's slice metadata)

Expected result (bug fixed)

With fix.diff applied, the bcopy is capped at MAX_SLICES; the trigger returns nslices=130 (the live count is unchanged) but no heap overrun occurs and no panic follows under any amount of churn.

Files

Notes

• python3 is not on the DragonFly guest by default; generate overflow.img on a host and ship it.
• Only >= 15 GPT entries are needed for dss_nslices > MAX_SLICES (dss_nslices = 2 + i); the PoC uses the maximum 128 for the largest overrun.
• The overflow source (dsmakeslicestruct, 130 slots) is correctly allocated; only the DIOCGSLICEINFO destination is undersized.

DF-0074 — VERDICT

Verdict: REPRODUCED (kernel heap overflow -> panic) on master DEV

The DIOCGSLICEINFO heap-buffer overflow described in the finding is real, present in the current DragonFlyBSD master DEV kernel, and was reproduced as a kernel panic on every fresh-boot attempt. The overflow is mathematically deterministic on every invocation; the resulting crash site is heap-layout dependent (three distinct panic signatures observed across three fresh-boot runs, all from the same 28 KB overrun).

Guest tested: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly v6.5.0.1712.g89e6a-DEVELOPMENT #1: Mon Jun 29 14:18:01 UTC 2026 x86_64 / X86_64_GENERIC (the audit's master DEV build).

Root cause (confirmed line-by-line in sys/)

The DIOCGSLICEINFO handler copies the live kernel struct diskslices into the ioctl data buffer using a length derived from the actual slice count, but the destination buffer is only sized for MAX_SLICES = 16 slots:

/* sys/kern/subr_diskslice.c:556-559 */
case DIOCGSLICEINFO:
    bcopy(ssp, data, (char *)&ssp->dss_slices[ssp->dss_nslices] -
                     (char *)ssp);
    return (0);

• Destination size: DIOCGSLICEINFO is _IOR('d', 111, struct diskslices) (sys/sys/diskslice.h:96). mapped_ioctl allocates the data buffer with size = IOCPARM_LEN(com) = sizeof(struct diskslices) = offsetof(dss_slices) + MAX_SLICES * sizeof(struct diskslice) = 32 + 16 * 256 = 4128 bytes (sys/kern/sys_generic.c:668,675).
• Source size for a GPT disk: subr_diskgpt.c:175 calls dsmakeslicestruct(BASE_SLICE + MAX_GPT_ENTRIES, info) = 130 slots (BASE_SLICE = 2, MAX_GPT_ENTRIES = 128), and subr_diskgpt.c:222 sets ssp->dss_nslices = BASE_SLICE + i (= 130 for any GPT whose header entries >= 128). dsmakeslicestruct (subr_diskslice.c:720-723) kmallocs the full 130-slot object, so the source is in-bounds — only the destination overflows.
• The overflow: the bcopy length becomes offsetof(dss_slices) + dss_nslices * sizeof(struct diskslice) = 32 + 130 * 256 = 33312 bytes, written into the 4128-byte data buffer → 29184 bytes (~28 KB) of overrun past the end of an M_IOCTLOPS slab object, on every call. The overrun bytes are attacker-influenced (ds_offset, ds_size, ds_type_uuid, ds_stor_uuid come straight from the crafted GPT entries — subr_diskgpt.c:237+).
• The trailing copyout (sys_generic.c:730) only copies the declared sizeof(struct diskslices) back, so the corruption is confined to kernel heap (the user merely observes dss_nslices = 130).

Struct sizes were verified on the guest with a small probe: sizeof(struct diskslice) = 256, sizeof(struct diskslices) = 4128, offsetof(dss_slices) = 32, overflow = (130-16)*256 = 29184 (~28 KB).

Trigger & evidence

A crafted 1 MiB GPT image (build_gpt.py, header entries = 128, 17 non-nil entries) is attached with vnconfig -c vn0 overflow.img. The kernel auto-probes the GPT and creates /dev/vn0s0../dev/vn0s16 (already proving dss_nslices > 16). Issuing DIOCGSLICEINFO on /dev/vn0s1 returns nslices=130 — proof the oversized bcopy executed — and writes 28 KB past the data buffer into adjacent kernel heap.

Three fresh-boot runs (via vm.sh reset -> clean-install) all panicked, each at a different downstream site of the same slab corruption (see panic.txt):

Run 3 is especially telling: the overflow corrupted slab objects describing the unrelated root disk (vbd0s1d), demonstrating the overrun reaches arbitrary adjacent kernel state — not just the crafted vn0 disk. The panic: slaballoc: corrupted zone (Run 2) is the most direct signature: the slab allocator's zone-consistency assertion fired because of the overflow.

The crash is asynchronous and probabilistic in exact site/timing (the overrun corrupts whatever slab object happens to be adjacent at runtime), but the underlying 28 KB heap overflow is 100% deterministic on every call — nslices=130 is returned on every single invocation, including the ~15 runs that did not immediately panic.

Reachability / privilege (severity calibration)

• Default devfs: slice device nodes (/dev/vn0*, /dev/md0*, /dev/serno/*/s*, /dev/vbd0*) are root:operator crw-r-----, and the operator group contains only root (/etc/group: operator:*:5:root). An unprivileged user (maxx, uid 1001) gets open: Permission denied (EACCES) — confirmed on the guest. So on a default single-user/workstation box the bug is root-only to trigger directly.
• However, the same defect is reachable by any principal that can open a slice device and issue the ioctl: any user in the operator group, any devfs ruleset that exposes slice devices to a group/class (common on multi-user servers, build/jail hosts, disk-inspection utilities, container/VM hosts that pass through storage), and any disk-probing utility that runs with such access. Presenting the crafted image via USB mass storage reaches the auto-probe path with no ioctl needed from the attacker for the dss_nslices inflation; only the DIOCGSLICEINFO (or any consumer of the raw-struct ioctl) needs to fire.
• Primitive: a deterministic ~28 KB attacker-influenced kernel-heap write (CWE-122). Reliable kernel-panic DoS is trivially demonstrated. With slab grooming (spray victim objects carrying function pointers / ucred * / refcounts into the M_IOCTLOPS neighborhood adjacent to the 4128-byte allocation, punch a hole, trigger the overflow into it), the corruption is convertible to kernel-mode code execution / local privilege escalation. The overflow size (28 KB) and the attacker-controlled content make this a strong primitive; full LPE was not developed in this verification pass (time-bounded), but the path is open.

PoC changes made during verification

1. trigger_stress.c (new): the original trigger.c only issues a single DIOCGSLICEINFO. On master DEV the single-shot overflow did not synchronously panic (the corrupted neighbor wasn't exercised in-band). trigger_stress.c issues the ioctl, then churns the slab allocator (open/close 64 fds, fork/exit 40 children) and a 16-process parallel flood to force a corrupted neighbor to be allocated/freed/validated, reliably surfacing the panic within a run. The original trigger.c is retained as the minimal proof (it returns nslices=130, proving the overflow).
2. build.sh / run.sh (new): self-contained, runnable reproduce scripts. run.sh documents that it must run as root (or operator) and that the panic is asynchronous (proof in dfbsd-qemu/boot.log).
3. Image build clarified: python3 is not installed on the DragonFly guest, so build_gpt.py runs on a host with python3 and the resulting overflow.img is shipped to the guest. build.sh warns if the image is missing.
4. Device naming: DragonFly uses /dev/vn0s1 + vnconfig -c vn0 (the original PoC text referenced NetBSD-style /dev/vnd0s1 / vnd0 / mdconfig, none of which apply here — mdconfig is absent on this guest).

No attack-logic changes were needed; build_gpt.py produced a valid GPT (header entries=128, correct CRCs) on the first host-side run and the kernel probed it correctly.

Recommended fix

fix.diff (validates with both git apply --check and patch --dry-run): cap the bcopy length at MAX_SLICES so it never exceeds the destination buffer size. This matches the finding markdown's ## Recommended fix proposal (the same one-line clamp), with an added explanatory comment and a local u_int ncap to keep the bcopy expression readable. The deeper fix (replacing the raw-struct ioctl with a structured, pointer-free output — see DF-0075) remains desirable but is out of scope for this minimal bounds fix.