DF-2946 — kern.stathz boot tunable fetched with no validation → boot-time integer divide fault

sys/kern/subr_param.c:202 (init_param1) overwrites the computed stathz (default hz + 1) with the raw loader tunable kern.stathz and never validates it. The value flows into initclocks_other() (sys/kern/kern_clock.c:438-441), which registers the per-CPU statclock systimer with SYSTF_MSSYNC. _systimer_init_periodic() (sys/kern/kern_systimer.c:270-273) then computes the timer period with an unguarded division:

if ((flags & SYSTF_MSSYNC) && freq <= 1000)
        info->periodic = sys_cputimer->fromhz(1000) * (1000 / freq);  /* 1000/0 */
else
        info->periodic = sys_cputimer->fromhz(freq);                  /* freq/freq */

and cputimer_default_fromhz() (sys/kern/kern_cputimer.c:197-200) divides sys_cputimer->freq / freq on the other branch.

• kern.stathz="0" → integer divide fault panic during boot (demonstrated).
• kern.stathz="-N" → signed period, garbage modulo/expiry math, broken statclock.
• kern.stathz huge → multi-GHz statclock (interrupt storm / unusable system).

Sibling of DF-0173 (kern.hz=0 divides at subr_param.c:204-207 inside init_param1); this member survives init_param1 and detonates later, at SI_BOOT2_POST_SMP. The clkinfo sysctl handler even guards for this (stathz ? stathz : hz, kern_clock.c:1337) — the systimer path does not.

Reproduce (host side, guest up & clean)

dfbsd-qemu/vm.sh run_root 'cp /boot/loader.conf /boot/loader.conf.df2946bak && printf "kern.stathz=\"0\"\n" >> /boot/loader.conf && sync'
dfbsd-qemu/vm.sh run_root 'shutdown -r now'
sleep 75; dfbsd-qemu/vm.sh status     # -> down
grep -n "Fatal trap" dfbsd-qemu/boot.log
dfbsd-qemu/vm.sh reset with-src

Expected output

Guest never reaches ssh (vm.sh status → down ~75 s after reboot command); serial console (dfbsd-qemu/boot.log, see panic.txt) shows, immediately after "Initialize MI interrupts for 6 cpus":

Fatal trap 18: integer divide fault while in kernel mode
cpuid = 0; lapic id = 0
...
kernel: type 18 trap, code=0
CPU0 stopping CPUs: 0x0000003e
Stopped at      -0x7f9a53d9:    idivq   %r12,%eax
db>

Impact: unbootable system (boot-time kernel panic). Trust boundary: /boot/loader.conf (root / loader prompt / console), same as DF-0173.

DF-2946 — VERDICT

Status: reproduced (impact: panic — boot-time kernel divide fault; single-variable, pristine guest)

What was run

Stock guest, kernel DragonFly 6.5-DEVELOPMENT #0 (INVARIANTS build, X86_64_GENERIC, 6 vCPU, 4 GB). Single change: one line appended to /boot/loader.conf:

kern.stathz="0"

then shutdown -r now.

What happened (vs. what was predicted)

Predicted: 1000 / freq (kern_systimer.c:271, SYSTF_MSSYNC path, or fromhz() at kern_cputimer.c:199) traps during initclocks_other() (SI_BOOT2_POST_SMP).

Observed (dfbsd-qemu/boot.log, full excerpt in panic.txt): the kernel boots through init_param1 without complaint (kern.stathz=0 is merely assigned — subr_param.c:202 has no validation), gets through SMP/MI-interrupt initialization ("Initialize MI interrupts for 6 cpus"), and dies with:

Fatal trap 18: integer divide fault while in kernel mode
cpuid = 0; lapic id = 0
kernel: type 18 trap, code=0
CPU0 stopping CPUs: 0x0000003e
Stopped at      -0x7f9a53d9:    idivq   %r12,%eax
db>

idivq = the 64-bit signed division of the period computation; the boot position matches initclocks_other() exactly (it runs right after MI interrupt init for all CPUs, before userland). Guest sits in DDB; ssh never comes up; vm.sh status → down. Reproduced on the first attempt; single variable planted (loader.conf otherwise untouched).

Why it is a finding and not a duplicate

• DF-0173 covers kern.hz=0 → division inside init_param1 (subr_param.c:204-207: ustick/nstick/ntp_default_tick_delta). With kern.stathz=0 alone, hz stays 100, those divisions succeed, the system passes init_param1 — and dies later in the systimer subsystem.
• DF-2915/2916/2917 are sleepq/systimer API defects, not clock-tunable validation.
• The codebase itself knows stathz can be zero — sysctl_kern_clockrate exports stathz ? stathz : hz (kern_clock.c:1337) — but the systimer registration path (kern_clock.c:439) passes it unguarded.

Trust boundary / severity

Boot-tunable (loader.conf / loader prompt / console) — requires root or boot-loader control, identical to DF-0173 (rated Low). No post-boot or unprivileged write path exists (kern.stathz has no runtime sysctl; maxprocperuid is RW but stathz is not). Ceiling: unbootable system. Rated Low (local boot DoS, privileged trigger), consistent with DF-0173.

Negative results worth recording

• kern.nbuf="-1048576" was planted first-hand and did not break boot: every nbuf cap in cpu_startup (machdep.c:424-458) compares long nbuf against unsigned vm_offset_t expressions, so the negative value is promoted to a huge unsigned, "capped due to kvm" then "due to physmem", and the system boots with a sane positive nbuf (129940 on this guest, warnings in boot.log). The apparent negative-nbuf valloc-corruption hypothesis is refuted on pc64 (same unsigned arithmetic in vkernel64 autoconf.c:156-158 rescues it there too).
• MSGBUFSIZE/msgbuf sizing: compile-time only (opt_msgbuf.h), no kenv tunable anywhere — not attacker-influenced in this threat model.
• maxthrssiz is fetched (subr_param.c:230) but has zero consumers in the tree — dead knob.
• vmm_vendor[16] is written only from the 12-char CPUID hypervisor signature (initcpu.c:195,204, memcpy of 13 bytes incl. NUL) — bounded, hardware-trusted.
• 32-bit limsize overflow in init_param2 is unreachable: only pc64 and vkernel64 call it (both 64-bit; (size_t)physpages * PAGE_SIZE ≤ 2^43).
• kern.hz > 1000000 → ustick == 0 → post-boot unprivileged divide-by-zero via tv.tv_usec / ustick (kern_time.c:511 and ~8 more sites) — same root cause and fix locus as DF-0173 (hz validation in init_param1); noted here to make the fix clamp the upper bound too, not re-filed as a separate finding.

Fix validation

Not performed in-guest (Low-severity boot-DoS class, no demonstrated memory corruption; kernel rebuild cycle not warranted for a 3-line clamp). fix.diff is authored against the read-only sys/ tree: validate hz/stathz in init_param1, plus a defense-in-depth freq <= 0 guard in _systimer_init_periodic.