DF-2815 — kern_shutdown.c: unsynchronized dumper global (set/clear TOCTOU, torn copy, clear/swap during active dump)

What

sys/kern/kern_shutdown.c keeps the registered crash-dump device in a global struct dumperinfo dumper (kern_shutdown.c:137) with zero serialization:

• set_dumper() (kern_shutdown.c:948-961) does an unlocked check-then-write (if (dumper.dumper != NULL) return EBUSY; dumper = *di;) and set_dumper(NULL) bzero()s the 40-byte struct in place.
• dumpsys() (kern_shutdown.c:980-983) checks dumper.dumper != NULL and then passes &dumper (the global itself, not a snapshot) to md_dumpsys(), whose dump loops re-read di->priv, di->maxiosize, di->blocksize, di->mediasize on every block write (sys/platform/pc64/x86_64/minidump_machdep.c:95,143,348,427 and dump_machdep.c:124,144,168,188).

The only writers are reached via disk_dumpconf() (sys/kern/subr_disk.c:915): the DIOCGKERNELDUMP ioctl (subr_disk.c:1186-1188 — no privilege check and no lock; see DF-2743), and sysctl kern.dumpdev (kern_shutdown.c:715-726 — root-gated by SYSCAP_NOSYSCTL_WR, kern_sysctl.c:1446, and serialized only against other sysctl writes via the oid lock, which the ioctl path does not take).

Impact

1. Clear during dump (demonstrated): a DIOCGKERNELDUMP clear landing after dumpsys() passed its check leaves di->priv == NULL for the next dev_ddump() → dev_needmplock(NULL) reads NULL->si_ops (sys/kern/kern_device.c:119-122) → kernel page fault while dumping (panic in the reboot/panic path instead of a clean dump/reboot).
2. Swap during dump: a concurrent set for a different device swaps priv mid-dump → the remainder of kernel memory is written to a different physical device at the current dump offset.
3. Torn registration (set vs set): two concurrent sets both pass the EBUSY check and interleave their 40-byte struct copies → mixed priv/mediaoffset/mediasize/blocksize from two devices → a later dump computes dumplo from one device's geometry but writes through another device's priv → silent destructive disk writes at the wrong offset on the wrong device (disk corruption; if the dump target is readable by a less-privileged user, kernel-memory disclosure).

Exploit ceiling (assessed, not demonstrated): the dumper function-pointer field can only ever be diskdump or NULL (only disk_dumpconf() builds registrations), and priv is only a referenced cdev — no attacker-chosen function pointer or forged object is possible, so the primitive tops out at kernel-panic DoS (proven) plus destructive wrong-device dump writes (code-proven). Not an LPE on its own.

Privilege needed: an open fd on a disk device (root, or group operator with default 0640 nodes; unprivileged only in combination with DF-2743's missing ioctl privilege check), plus a dump in progress (root reboot -d, shutdown -d, or any kernel panic while churn runs).

Reproduce

Guest: DragonFly 6.5-DEVELOPMENT x86_64, stock X86_64_GENERIC (INVARIANTS).

1. sh build.sh — compiles churn and rebootdirect in the guest.
2. Baseline: /root/rebootdirect alone → serial console shows Dumping ... Dump complete then reboot.
3. Race: nohup /root/churn /dev/vbd0s1b 900 3 4 & /root/rebootdirect (mode 3 = mostly-set with a clear every 64th ioctl; see run.sh). Expected on the vulnerable kernel: mid-dump Fatal trap 12: page fault ... fault virtual address = 0xa8 ... dev_ddump() at dev_ddump+0xc / blk_write() — the NULL di->priv dereference — see panic.txt.
4. Patched: apply fix.diff, make nativekernel && make installkernel, reboot, repeat step 3 → Dump complete despite the churn.

Files: churn.c (ioctl churner), rebootdirect.c (single-threaded direct reboot(2) caller), run.sh, panic.txt (decisive serial-log excerpt), serial.race9.log (full serial log), run.baseline.log (clean baseline dump), fix.diff (verified fix: spinlock + snapshot), build.log.

Notes

• The churn must be a separate process from the reboot(2) caller: the caller's own process is torn down by shutdown_cleanup_proc() (see DF-2816) before the dump, and console writes freeze in polled mode, so in-loop logging/markers contaminate the experiment.
• With the default sync-enabled reboot the churner reliably survives into the dump window only when the reboot(2) caller skips the sync/unmount phase; rebootdirect uses RB_NOSYNC|RB_DUMP to reach dumpsys() quickly (kern_shutdown.c:393) while the churner is provably alive.

DF-2815 VERDICT — REPRODUCED (kernel panic while dumping; unsynchronized dumper global)

Bottom line

The global struct dumperinfo dumper in sys/kern/kern_shutdown.c is written by set_dumper() (kern_shutdown.c:948-961) with no lock and no atomicity: the EBUSY check is a check-then-act TOCTOU, the registration is a 40-byte struct copy, and the clear path is an in-place bzero(). dumpsys() (kern_shutdown.c:980-983) checks dumper.dumper != NULL and then hands the global itself (&dumper) to md_dumpsys(), whose write loops re-read di->priv for every block (minidump_machdep.c:95,143,348,427). A concurrent DIOCGKERNELDUMP clear (subr_disk.c:1186-1188 → disk_dumpconf(dev,0) → set_dumper(NULL), no lock, no privilege check on the ioctl itself — DF-2743) that lands after dumpsys()'s check NULLs di->priv mid-dump, and the next dev_ddump(NULL, ...) dereferences NULL->si_ops in dev_needmplock() (kern_device.c:119-122) → page fault while dumping.

Reproduction (MARK-9, stock INVARIANTS kernel)

• churner: separate root process, 4 threads, ioctl(DIOCGKERNELDUMP) mostly "set" with a clear every 64th ioctl on /dev/vbd0s1b (the configured dump device).
• trigger: single-threaded rebootdirect calls reboot(2) with RB_AUTOBOOT|RB_DUMP|RB_NOSYNC (NOSYNC skips the sync/unmount phase so the dump starts while the churner is provably alive — the kproc-wait phase still shows churn progress markers in the diagnostic runs).
• Result (serial console, see panic.txt / serial.race9.log):

Dumping 666 MB:Fatal user address access from kernel mode from rebootdirect at ffffffff8062d3fc
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic id = 0
fault virtual address    = 0xa8
current process          = 843 (rebootdirect)
current thread           = pri 31 (CRIT)
panic: page fault
dev_ddump() at dev_ddump+0xc
blk_write() at blk_write+0x9a

dev_ddump+0xc is dev_needmplock(dev) → dev->si_ops->head.flags at offset 0xa8 of a NULL dev — i.e. di->priv == NULL, the just-bzeroed global. Fault on cpu0 (the dumping CPU), in the rebooting thread, mid-dump ("Dumping 666 MB:" printed, no progress steps yet). This is the exact predicted primitive, 1/1 once the churner was kept alive into the dump window.

Earlier attempts that did NOT reproduce taught the setup constraints (attempts 1-4): (a) the churner must not be a thread of the rebooting process — boot() tears that process down first (that is DF-2816, which panicked the box via naccess instead); (b) the churner must not touch the root filesystem or console after shutdown starts — the forced unmount blocks those writes forever and freezes the churn threads before the dump; (c) reboot -d/reboot -dq (init-mediated) kills or starves the churner before dumpsys, so the reboot(2) must be issued directly by an unrelated single-threaded helper; (d) with the default sync-enabled path the window is still reachable but far narrower — RB_NOSYNC makes it deterministic.

Exploit chain / escalation ceiling (rigorously assessed)

• Proven: unprivileged-to-root N/A; requires an open fd on a disk device (root; operator group on default 0640 nodes; unprivileged only via DF-2743's missing ioctl privilege check in setups where such nodes are openable) plus a dump in progress (root reboot -d / any panic while churning). Demonstrated as root: kernel panic during the dump path (panic-in-reboot; in the panic path it would be a double panic).
• Code-proven but not run (would be destructive to the guest disk): the set-vs-set TOCTOU interleaves two 40-byte struct copies and can mix priv (device A) with mediaoffset/mediasize/blocksize (device B), so a subsequent dump computes dumplo (dump_machdep.c:313-318) from B's geometry but writes through A's device → kernel memory written at a wrong offset on the wrong device: silent disk corruption, and RAM/kernel disclosure if the misdirected dump target is user-readable.
• NOT achievable with this bug: user→root. The dumper function-pointer field can only be diskdump (subr_disk.c:931) or NULL — no attacker- chosen function pointer, no forged object; priv is only a referenced cdev. The primitive tops out at NULL-deref (DoS) and destructive dump misdirection. uid0 escalation would require a separate function-pointer forgery primitive that this race does not provide.

Fix validation

fix.diff (in this pack; git-apply --check'd against the read-only tree): a dumper_lock spinlock serializing set_dumper()/clear, and dumpsys() taking a stack snapshot of the dumper under the lock and passing the snapshot to md_dumpsys() (safe: md_dumpsys/minidumpsys only read di fields — verified by audit of both files). Applied to the guest's /usr/src copy, make nativekernel && make installkernel, rebooted into the patched kernel, re-ran the exact MARK-9 PoC: the dump completes ("Dump complete") despite identical churn — see run.patched.log. Baseline (unpatched) signature (mid-dump page fault at dev_ddump+0xc) is gone.

Kernel references

• sys/kern/kern_shutdown.c:137 (global), :948-961 (set_dumper), :963-984 (dumpsys check + &dumper handoff)
• sys/kern/subr_disk.c:1186-1188 (unlocked, unprivileged ioctl entry), :915-939 (disk_dumpconf builds the registration)
• sys/kern/kern_device.c:119-122,423+ (dev_needmplock NULL deref sink)
• sys/platform/pc64/x86_64/minidump_machdep.c:95,143,348,427 (per-write di->priv re-reads); dump_machdep.c:313-318 (geometry math)