DF-3005 — Read-after-free of cdev->si_name in devfs_destroy_related_without_flag_worker

• File: sys/vfs/devfs/devfs_core.c:1499-1520 (bug at 1511-1513)
• Class: CWE-416 use-after-free (read), kernel
• Severity: Low
• Reach: root via disk ioctls (DIOCSDINFO / DIOCSYNCSLICEINFO), or any physical disk hotplug/media change that triggers a disk reprobe. Not directly unprivileged (requires writing a disklabel / MBR).

Build

Nothing to compile: trigger.sh uses stock tools (vnconfig, fdisk, disklabel).

sh trigger.sh        # as root on the guest

Expected

With vfs.devfs.debug=3, the serial console shows, per destroyed related device:

make_dev called for vn0s1
related_wo_flag: vn0            <- pre-destroy trace (safe)
related_wo_flag: vn0s0          <- pre-destroy trace (safe)
related_wo_flag: vn0s0 restart  <- POST-FREE READ (devfs_core.c:1512)
related_wo_flag: vn0
related_wo_flag: vn0s1

The restart line is emitted by code that executes after devfs_destroy_dev_worker(dev) has released the last three references of a never-opened slice device (make_dev = exactly 3 refs: sysref_activate + reference_dev in devfs_new_cdev, + reference_dev in devfs_create_dev; the destroy worker releases exactly those 3), so the cdev has been through devfs_cdev_terminate -> sysref_put -> back to the sysref objcache. dev->si_name is then loaded as a function argument — this argument evaluation happens at any debug level (devfs_debug is an ordinary function, not a macro), so production kernels perform the same load.

Observed output for this run is in run.log.

Why it matters / why only Low

The read is 1..(SPECNAMELEN+1) bytes out of a freed-but-still-mapped objcache chunk. No crash and no user-visible disclosure on the stock kernel: the freed chunk normally retains its old contents, so the printed name looks normal. If the chunk is reused before the read, the console (and msgbuf, if readable by the invoking context) receives whatever the new occupant put there up to the first NUL. There is no write primitive and no direct unprivileged trigger, hence Low.

Fix

fix.diff moves the devfs_debug() ahead of devfs_destroy_dev_worker() (argument then refers to a live cdev). Validated in the fix build (see VERDICT.md).

DF-3005 VERDICT

Status: reproduced (code path + read-after-free by construction) — impact: none observable / Low.

What was run

Guest: DragonFly 6.5-DEVELOPMENT #0 (stock INVARIANTS kernel), vm.sh QEMU/KVM.

kldload vn; dd 64MB img; vnconfig -c vn0 img
sysctl vfs.devfs.debug=3
fdisk -I vn0          # writes MBR -> DIOCSYNCSLICEINFO -> DISK_DISK_REPROBE
disklabel -w vn0 auto # DIOCWDINFO -> DIOCSDINFO -> DISK_SLICE_REPROBE

Serial console (vm.sh log) captured in run.log:

make_dev called for vn0s1
related_wo_flag: vn0
related_wo_flag: vn0s0
related_wo_flag: vn0s0 restart      <-- devfs_core.c:1512, after the free
related_wo_flag: vn0
related_wo_flag: vn0s1

Why this proves the read-after-free

1. subr_diskslice.c:646 (DIOCSYNCSLICEINFO) and :610/:671 (DIOCSDINFO / DIOCWDINFO) send DISK_DISK_REPROBE / DISK_SLICE_REPROBE to the disk thread.
2. subr_disk.c:574,584 call devfs_destroy_related_without_flag(dev, SI_REPROBE_TEST), which reaches devfs_destroy_related_without_flag_worker on the devfs core thread (sys/vfs/devfs/devfs_core.c:1499).
3. For every related cdev lacking SI_REPROBE_TEST, line 1511 calls devfs_destroy_dev_worker(dev) (devfs_core.c:1440), which runs devfs_unlink_dev + devfs_propagate_dev + three release_dev(dev) calls (lines 1453-1456).
4. vn0s0/vn0s1 slice devices were created moments before by make_dev (log: "make_dev called for vn0s1") and were never opened (devfs_spec_open appears only for vn0), so their reference count is exactly the three references make_dev takes (kern_conf.c:189-212: devfs_new_cdev -> sysref_activate + reference_dev, then devfs_create_dev -> reference_dev). Three releases -> count 0 -> release_dev -> sysref_put -> devfs_cdev_terminate (devfs_core.c:2487) -> cdev returns to the sysref objcache: freed.
5. Immediately after the worker returns, line 1512-1513 evaluates dev->si_name as an argument to devfs_debug(). C argument evaluation is unconditional — the load happens even with vfs.devfs.debug=0, on every production kernel taking this path.

The printed name looks intact only because the freed objcache chunk had not been reused yet. If reused, the console/msgbuf receives foreign bytes up to the first NUL.

Exploitability assessment (per contract: push toward uid=0)

No path to privilege escalation:

• The primitive is a single kernel-side read of ≤ 33 bytes from a specific offset inside a just-freed struct cdev; the destination is a kvprintf format argument, not a user copyout.
• The output channel is the kernel console / msgbuf. On a default system the invoking context is root (disklabel/fdisk) or the disk thread (hotplug); there is no unprivileged synchronous feedback loop (no name is returned to an unprivileged requester), so the read cannot be converted into an info leak oracle for an unprivileged user.
• No write primitive, no lifetime extension, no refcount confusion remains (the object is already dead and the read is the last touch).

Hard blocker for escalation: attacker does not control the destination or the timing of the read, and cannot keep the chunk allocated past the free (objcache free is immediate and uncontested here).

Fix validation

fix.diff (move devfs_debug before devfs_destroy_dev_worker) applied in the guest /usr/src; make nativekernel + installkernel (build log: /tmp/kbuild.log in guest, summarized in build_fix.log here). Re-running the trigger on the patched kernel shows the same related_wo_flag: ... restart line — now provably reading a live cdev — with no panic or regression, and the DF-3006 leak PoC simultaneously confirms the tree is behaving (see that pack). Baseline vs patched output is byte-identical because the freed chunk retained its contents — that is expected for this bug class and documented here rather than hidden.