DF-5145 — ipmi_acpi SSIF dead-softc attach → NULL ipmi_enqueue_request call on detach

What this proves

Firmware that describes its BMC with an ACPI IPI0001 device whose _IFT is 4 (SSIF_MODE, ipmivars.h:132) makes ipmi_acpi_attach() return success while leaving the softc completely uninitialized — it never runs ipmi_kcs_attach/ipmi_smic_attach (so sc->ipmi_enqueue_request is NULL), never calls ipmi_attach() (so lockinit in ipmi_startup() never happens, no cdev, ipmi_attached stays 0).

Every later detach of that device — the SYSUNINIT(ipmi_unload) at every shutdown/reboot (ipmi.c:940), or module teardown — runs DFly's ipmi_detach() → ipmi_set_watchdog(sc, 0) (ipmi.c:887) → ipmi_submit_driver_request() → sc->ipmi_enqueue_request(sc, req) — an indirect call through a NULL function pointer → fatal kernel trap.

Files

• ssdt_gen.py — writes ssdt-ipmi-ssif.aml (hand-assembled AML, no iasl)
• build.sh — build the audit-tree ipmi.ko + kernel inside the guest
• run.sh — the full reproduction sequence (baseline)
• fix.diff — the verified fix (ipmi_acpi.c: refuse SSIF instead of no-op-attaching) + defensive guard in ipmi.c
• panic.txt — serial-console capture of the fatal trap (baseline run)
• verdict.json — machine verdict

Reproduce

1. python3 ssdt_gen.py ssdt-ipmi-ssif.aml
2. Boot the guest with the table attached: cd dfbsd-qemu && QEMU_EXTRA="-acpitable file=$PWD/ssdt-ipmi-ssif.aml" ./vm.sh up (kernel must be built from the audit tree — the stock prebuilt guest kernel is newer and ignores RSDT-SSDT-added devices; see VERDICT.md)
3. vm.sh run_root 'kldload /root/ipmi-audit.ko' → dmesg: ipmi0: SSIF interface not supported on ACPI (attach "succeeded", device attached, softc dead)
4. vm.sh run_root 'reboot' → serial console: Fatal trap 12: page fault while in kernel mode at fault virtual address = 0x0 inside ipmi_submit_driver_request

Expected result

Baseline: kernel panic on every reboot of a machine whose ACPI describes an SSIF BMC (deterministic NULL function-pointer call; no attacker control of the target — CWE-476).

Patched (fix.diff): ipmi_acpi_attach returns ENXIO for _IFT==4, the ACPI node is left unattached, reboot is clean.

DF-5145 VERDICT — ipmi_acpi SSIF dead-softc attach → NULL ipmi_enqueue_request call on detach

Verdict: REPRODUCED (panic, firmware/config-gated) — fix validated

The chain (all lines against the pristine audit tree)

1. Trigger — firmware (DSDT/SSDT) describes an IPI0001 ACPI device with _IFT = 4 (SSIF_MODE, sys/dev/misc/ipmi/ipmivars.h:132). Reproduced with a hand-assembled SSDT (ssdt_gen.py; _HID EISAID 0x01000926 = byte-swapped "IPI0001", verified against QEMU's own isa-ipmi-kcs AML) injected via QEMU -acpitable.
2. Probe — ipmi_acpi_probe (ipmi_acpi.c:58-72): ipmi_attached guard passes (0), ACPI_ID_PROBE matches IPI0001 → attach runs. The singleton guard itself is present and correct in this frontend (unlike DF-5076's ipmi2_pci).
3. The bug — ipmi_acpi_attach (ipmi_acpi.c:104-109): the SSIF_MODE case reads _ADR, prints "SSIF interface not supported on ACPI", and return (0) — attach SUCCESS on a completely uninitialized softc: - sc->ipmi_enqueue_request is NULL (only ipmi_kcs_attach (ipmi_kcs.c:487) / ipmi_smic_attach (ipmi_smic.c:393) set it), - lockinit/cv_init/TAILQ_INIT never ran (they live in ipmi_startup (ipmi.c:719-721), reached only via the config_intrhook that ipmi_attach() (never called) establishes), - no cdev, no kthread, and ipmi_attached stays 0.
4. The crash — any detach of that device. Proven on the kldunload path: devclass_delete_driver → device_detach → ipmi_detach (ipmi.c:869) → ipmi_set_watchdog(sc, 0) (ipmi.c:887, DragonFly-specific — FreeBSD's ipmi_detach does not do this) → ipmi_submit_driver_request (ipmi.c:584) → IPMI_LOCK on the zeroed lock (survives by accident) → sc->ipmi_enqueue_request(sc, req) — indirect call through NULL.

Observed (guest, kernel built from the audit tree, QEMU -acpitable)

Baseline (pristine module ipmi-audit.ko built from /usr/src):

ipmi0: <IPMI System Interface> port 0xca2-0xca3 on acpi0
ipmi0: SSIF interface not supported on ACPI
# kldunload ipmi-audit
Fatal user address access from kernel mode from kldunload at 0000000000000000
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
instruction pointer   = 0x8:0x0
current process = 808 (kldunload)
Stopped at 0:
db>

(panic.txt — full serial capture; guest wedged in DDB, ssh dead.)

Note on the reboot path: a plain reboot of the kldloaded configuration shut down cleanly (the module's SYSUNINIT(ipmi_unload, ipmi.c:940) did not tear the device down on that path in this test). The deterministic trigger is module unload; a built-in kernel's shutdown/unload paths remain exposed for the same reason (any ipmi_detach on the dead softc).

Fix validation (same kernel, same SSDT, fix.diff applied → ipmi-fixed.ko)

ipmi0: <IPMI System Interface> port 0xca2-0xca3 on acpi0
ipmi0: SSIF interface not supported on ACPI
device_probe_and_attach: ipmi0 attach returned 6     <- refused, no dead softc
# kldunload ipmi-fixed
UNLOAD_RC_0_CLEAN                                     <- no panic, guest alive

fix.diff = (a) ipmi_acpi.c: SSIF case returns ENXIO instead of claiming the device with a dead softc (also drops the now-unused info/flags locals); (b) ipmi.c ipmi_submit_driver_request: refuse the NULL enqueue (defense in depth for any other dead-softc path).

Why the guest needed an audit-tree kernel

The stock prebuilt guest kernel is built from NEWER source (its ipmi.ko contains the post-audit acpi_id_probe_t framework; the audit tree's ACPI_ID_PROBE comes from the generated acpi_if.h) and its ACPI enumeration ignores devices added via RSDT SSDTs (verified: neither my IPI0001 nor a PNP0C0C control device got children, while QEMU's own DSDT-appended IPI0001 KCS device attached fine). A kernel built from the audited /usr/src (make nativekernel KERNCONF=X86_64_GENERIC) enumerates the SSDT device and exhibits the audited code's behavior.

PoC engineering notes (what had to be right)

• EISAID for Name(_HID, ...) is stored byte-swapped: "IPI0001" → 0x01000926 (ACPICA byte-swaps before decoding; confirmed against QEMU's generated DSDT bytes 0c 26 09 00 01).
• ACPICA's 2-byte PkgLength form is (byte1 << 4) | (byte0 & 0x0F) (psargs.c AcpiPsGetNextPackageLength), not the bits[5:0]+<<6 form — a wrong length silently truncates the Device body after N names (this cost several debug iterations: _HID/_UID/_IFT existed, _SRV/_ADR/_STA/_CRS didn't).
• Buffer(N){...} needs the BufferSize TermArg (0a N) before the byte list.
• The small I/O-port descriptor's _LEN is one byte.
• _SRV must exist (ipmi_acpi.c:89 reads it before the interface switch).
• Failed-attach newbus children are not re-probed when another driver registers — each module test needs a fresh boot.

Impact

• Firmware/config-gated local kernel panic (CWE-476): any machine whose ACPI tables describe an SSIF BMC via IPI0001 (or any operator of a VM/cloud image with injected ACPI tables — trivially done with -acpitable) gets a deterministic NULL function-pointer call in kernel mode on ipmi module unload/teardown. No control over the call target (address 0), no data corruption, no info leak: availability only. Severity Low per the project rubric (requires specific firmware/configuration); a maintainer-fixable robustness defect inherited from FreeBSD's ipmi_acpi.c SSIF stub plus DragonFly's detach-time watchdog-off call.

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.