DF-2948 — kern.ncallout fetched after the only clamp → int-truncated callwheel sizing → boot panic / latent OOB init

sys/kern/subr_param.c:327-330 clamps the computed ncallout to 5*60*hz and only then fetches the kern.ncallout tunable — which therefore enters the kernel with no bounds at all. The consumer swi_softclock_setup() (sys/kern/kern_timeout.c:374-413) does all its math in int:

target    = ncallout / ncpus + 16;                 /* :386 */
cwheelsize = 1;
while (cwheelsize < target) cwheelsize <<= 1;      /* :389-390 signed shift */
cwheelmask = cwheelsize - 1;
...
int wheel_sz;                                       /* :398 */
wheel_sz      = sizeof(*sc->callwheel) * cwheelsize;  /* :406  24 * 2^30 → 0 (mod 2^32) */
sc->callwheel = kmem_alloc3(kernel_map, wheel_sz, ...);  /* :407 zero-length alloc per CPU */
memset(sc->callwheel, 0, wheel_sz);
for (i = 0; i < cwheelsize; ++i)                   /* :410 2^30 OOB init writes */
        spin_init(&sc->callwheel[i].spin, "wheel");

sizeof(struct wheel) = 8 (spinlock) + 16 (TAILQ_HEAD) = 24 on x86_64, so wheel_sz = 24 * 2^30 = 25769803776 ≡ 0 (mod 2^32) truncates to 0.

• 6-vCPU guest (kern.ncallout=2147483647): target = 357913966 → cwheelsize = 2^30 → wheel_sz = 0 → six per-CPU zero-length kmem_alloc3(kernel_map, 0) calls collide → panic: vm_map_entry_link: dup addr during boot (demonstrated). Had the map not panicked first, the 2^30-iteration init loop would spin_init/TAILQ_INIT ~25 GB past a zero-byte allocation — an out-of-bounds kernel write.
• ≤2-vCPU boxes: target can be pushed into (2^30, 2^31) where the doubling loop executes 1 << 31 (signed overflow → negative → 0) and spins forever: infinite boot loop.
• Degenerate corner (target wrapped negative via ncallout + 16 overflow at INT_MAX on 1 CPU): cwheelsize stays 1 → every callout in one bucket → pathological softclock behavior.

Distinct from DF-0174 (ncallout overflow via unbounded kern.maxfiles): this is the direct tunable path, which no maxfiles clamp can reach, and the sink is the cwheelsize/wheel_sz int math in kern_timeout.c.

Reproduce (host side, guest up & clean)

dfbsd-qemu/vm.sh run_root 'cp /boot/loader.conf /boot/loader.conf.df2948bak && printf "kern.ncallout=\"2147483647\"\n" >> /boot/loader.conf && sync'
dfbsd-qemu/vm.sh run_root 'shutdown -r now'
sleep 80; dfbsd-qemu/vm.sh status     # -> down
grep -n "panic" dfbsd-qemu/boot.log
dfbsd-qemu/vm.sh reset with-src

Expected output

Guest never reaches ssh; serial console (panic.txt) shows, right after "Initialize MI interrupts for 6 cpus":

panic: vm_map_entry_link: dup addr map 0xffffffff8159aea0 ent 0xffffffff81709b18
cpuid = 0
Trace beginning at frame 0xffffffff817a9e30 ...
Debugger("panic")
CPU0 stopping CPUs: 0x0000003e
Stopped at      -0x7f433c74:    movb   $0,0xbd77f9(%rip)
db>

Impact: unbootable system. Trust boundary: /boot/loader.conf (root/loader prompt), same class as DF-0173/DF-0174.

DF-2948 — VERDICT

Status: reproduced (impact: panic — boot-time kernel panic via integer truncation in callwheel sizing; pristine single-variable run)

What was run

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

kern.ncallout="2147483647"

then shutdown -r now.

What happened (vs. what was predicted)

Predicted chain: TUNABLE_INT_FETCH("kern.ncallout", &ncallout) at subr_param.c:330 runs after the only clamp (5*60*hz, lines 328-329), so INT_MAX enters untouched → target = ncallout/ncpus + 16 = 357913966 → cwheelsize doubles to 2^30 → int wheel_sz = 24 * 2^30 truncates to 0 (mod 2^32) → six per-CPU kmem_alloc3(kernel_map, 0).

Observed (panic.txt): boot dies right after "Initialize MI interrupts for 6 cpus" — the SI_SUB_SOFTCLOCKS phase — with:

panic: vm_map_entry_link: dup addr map 0xffffffff8159aea0 ent 0xffffffff81709b18
Trace beginning at frame 0xffffffff817a9e30
Debugger("panic")
Stopped at      -0x7f433c74:    movb   $0,0xbd77f9(%rip)
db>

i.e. the second per-CPU zero-length callwheel allocation collided with the first in kernel_map and the map code panicked. The guest sat in DDB; ssh never came up; vm.sh status → down.

The panic fired before the predicted OOB stomp (for (i = 0; i < cwheelsize; ++i) spin_init(&sc->callwheel[i].spin, ...) — 2^30 × 24 bytes ≈ 25 GB of init writes past a zero-byte allocation, kern_timeout.c:410-413), so the demonstrated impact is boot DoS, while the code path clearly shows the latent memory-corruption consequence whenever the zero-length allocation does not trip the map assertion first (e.g. differing vm_map behavior, or values of ncallout that yield a small positive truncated wheel_sz with a huge cwheelsize, such as ncallout giving cwheelsize = 2^30 with sizeof 24 → 0; ncpus=1..2 with target in (2^30, 2^31) instead overflows the doubling loop 1 << 31 into an infinite boot loop).

Two runs performed: (1) with a stale kern.nbuf="-1048576" line still present — same panic (and that line had been separately proven harmless, see DF-2946 VERDICT.md negative results); (2) pristine single-variable re-run after vm.sh reset — identical panic, identical addresses.

Why it is a finding and not a duplicate of DF-0174

DF-0174 covers ncallout = 16 + maxproc + maxfiles overflow via unbounded kern.maxfiles. This finding is the direct tunable input: kern.ncallout is fetched after the only clamp in the file (subr_param.c:330 vs 328-329), so it bypasses every bound regardless of maxfiles, and the defective sink is the int target / int cwheelsize / int wheel_sz arithmetic in swi_softclock_setup (kern_timeout.c:386-407) — wheel_sz truncation to 0 and the signed-shift overflow are not reachable through the maxfiles path on multi-CPU boxes (maxproc is capped at limsize*40 ≈ 327k and even INT_MAX maxfiles only wraps the sum, which the 5*60*hz clamp then re-bounds when reached through line 327). Fixing DF-0174 by clamping maxfiles would leave kern.ncallout fully unclamped.

Trust boundary / severity

Boot tunable — requires root/loader-prompt/console. No runtime sysctl exists for ncallout (kern_mib.c has none; it is boot-only). Ceiling: persistent unbootable system. Rated Low (privileged boot DoS), consistent with DF-0173/DF-0174 ratings.

Fix validation

Not performed in-guest (Low boot-DoS class; the demonstrated manifestation is a panic, not corruption — the corruption path is latent behind the vm_map panic). fix.diff clamps kern.ncallout to the same 5*60*hz bound after the fetch (subr_param.c) and fixes the int math in swi_softclock_setup (size_t wheel sizing with overflow guard).