DF-4505 — VERDICT

REPRODUCED — kernel panic (local DoS) from an operator-group user, and the one-file fix is validated live on the same kernel.

Root cause

sys/dev/misc/ipmi/ipmi.c:

• ipmi_ioctl() IPMICTL_SEND_COMMAND (ipmi.c:401-416): every ioctl allocates sizeof(struct ipmi_request) + req->msg.data_len + IPMI_MAX_RX bytes (ipmi_alloc_request, ipmi.c:528-549; msg.data_len is unsigned short, max 65535 → ~66.6 KB per request) and enqueues it asynchronously.
• The only drain is a single kthread (kcs_loop, ipmi_kcs.c:449-469) that processes pending requests serially; each request is pushed over the KCS interface one byte per port-IO (ipmi_kcs.c:347-365), so service time per 64 KB request is five orders of magnitude larger than ioctl enqueue time.
• dev->ipmi_requests is a plain counter — nothing in the driver bounds it.
• When the M_IPMI kmem accounting limit is crossed, DragonFly's kmalloc panics: panic: ipmi: malloc limit exceeded.

Attack class: CWE-400 (uncontrolled resource consumption). Access class: /dev/ipmi0 is created 0660 root:operator (ipmi.c:831-832) — any local user in group operator (the designated semi-privileged class for this node; also the class DF-1661 was rated against). No hardware fault, misconfig, or root is needed: ~20,000 plain ioctls.

How it was reproduced (3x baseline, from fresh boots)

1. Guest booted with a simulated BMC so the surface is real: QEMU_EXTRA="-device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-kcs,bmc=bmc0", then kldload ipmi → ipmi0: KCS mode found at io 0xca2 on acpi, /dev/ipmi0 = crw-rw---- root operator.
2. maxx (uid 1001, groups: maxx + operator only) runs ./flood 60000 65535.
3. Observed: - 5,000 sends → v_free_count 847,167 → 762,987 (329 MB pinned — exactly 5000 × 66.6 KB of in-flight backlog; run1.partial.txt), - guest stops answering ssh; vm.sh status → down, - serial console: panic: ipmi: malloc limit exceeded with trace _kmalloc ← ipmi_alloc_request ← ipmi_ioctl ← dev_dioctl ← devfs_fo_ioctl (panic.txt, panic2.txt, panic.baseline-withsrc.txt — the third on the with-src snapshot kernel used for fix validation).

Honest scope: this is a kernel panic / availability bug, not a memory- corruption primitive — kmalloc fails cleanly before any write occurs, so there is no escalation path from this finding itself.

Fix validation (mandatory-quality evidence)

fix.diff (single file, applies clean with git apply):

• adds IPMI_MAX_REQUESTS 128 and, in SEND_COMMAND's final locked section, returns EBUSY when dev->ipmi_requests >= IPMI_MAX_REQUESTS (frees the just-allocated request);
• fixes the latent error path found during this audit: if ipmi_enqueue_request() ever fails (all three backends currently return 0 unconditionally — ipmi_kcs.c:487, ipmi_smic.c:393, ipmi_ssif.c:371), the counter is decremented and the request freed, instead of leaking both and hanging ipmi_dtor()'s drain loop forever (ipmi.c:226-230).

Baseline (same with-src snapshot kernel): panic, guest dead (panic.baseline-withsrc.txt). Patched: make nativekernel KERNCONF=X86_64_GENERIC && make installkernel, reboot, exact same PoC:

send 128 failed: Device busy
after flood (fd open)   v_free_count = 845510 pages (3302 MB)   # 128×66.6KB ≈ 8.1MB
after close+10s         v_free_count = 847545 pages (3310 MB)   # fully recovered

Guest stayed up; 5 additional sustained floods (5×20,000 sends) showed no panic and no cumulative leak (run.log). Residual exposure: the cap is per-open-handle (128 × 66.6 KB ≈ 8.5 MB per fd); a user may hold many fds. A per-ipmi_softc or per-cred cap would be a stricter follow-up.

Files (evidence)

• flood.c, build.sh, run.sh — exact PoC + commands
• run.log — patched-kernel decisive run, full output
• run1.partial.txt — first baseline run output (mid-flood 329 MB sample)
• panic.txt, panic2.txt, panic.baseline-withsrc.txt — three panic captures
• fix.diff, fix_build.log, fix_run.log — validated fix
• env.txt — guest environment

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.