DF-5153 — dpt_pci_attach() bus_setup_intr failure leaves XPT-registered SIMs, CAM paths, shutdown handler and softc live against released io/irq

File: sys/dev/raid/dpt/dpt_pci.c:163-179 (trigger), :159 (setup) Class: incomplete error-path unwind → logical UAF of bus resources + permanent leak + unkillable CAM I/O (CWE-459 Incomplete Cleanup) Severity: Low (hardware-gated: needs a DPT 0x1044:0xa400 HBA and an interrupt-registration failure at attach) Distinct from DF-2151 (known, not re-reported): DF-2151 is the wrong-rid bus_release_resource on the bad: path. This finding is everything else that path fails to unwind — the CAM/XPT lifetime, the shutdown handler, the DMA machinery and the softc. (Note the IRQ release at dpt_pci.c:176-177 uses rid 0, which is the rid the IRQ was allocated with at :103-105 — correct; only the io rid is wrong, and that half is DF-2151.)

The bug

dpt_pci_attach reaches bus_setup_intr only after the controller is fully brought online:

    crit_enter();
    if (dpt_init(dpt) != 0) { ... }          /* DMA tags, CCB array, sg maps */
    /* Register with the XPT */
    dpt_attach(dpt);                          /* dpt_pci.c:159 */
    crit_exit();

    error = bus_setup_intr(dev, irq, 0, dpt_intr, dpt, &ih, NULL);
    if (error) {
        device_printf(dev, "Unable to register interrupt handler\n");
        error = ENXIO;
        goto bad;                          /* dpt_pci.c:168 */
    }
    ...
bad:
    if (io)
        bus_release_resource(dev, iotype, 0, io);   /* wrong rid = DF-2151 */
    if (irq)
        bus_release_resource(dev, SYS_RES_IRQ, 0, irq);  /* correct rid */
    return (error);

By the time bus_setup_intr runs, dpt_attach (dpt_scsi.c:1450-1490) has:

• cam_sim_alloc'd up to MAX_CHANNELS SIMs sharing one devq and xpt_bus_register'd each (dpt_scsi.c:1466-1473),
• xpt_create_path'd wildcard paths for each (dpt_scsi.c:1475-1482),
• released the shared devq (dpt_scsi.c:1485),
• EVENTHANDLER_REGISTER'd shutdown_post_sync → dptshutdown, discarding the tag (dpt_scsi.c:1487-1488),

and dpt_alloc (dpt_scsi.c:1153-1169) has TAILQ-link'd the softc onto the global dpt_softcs list (:1165). None of this is undone on the failure path: bad: touches only io/irq; dpt_free is never called; no bus is deregistered; no sim/path freed; the shutdown handler stays registered; the softc stays on dpt_softcs; the DMA'able CCB array, sg maps and three DMA tags stay allocated forever.

Consequences (why it is not merely cosmetic)

1. Phantom SIM in CAM. xpt_bus_register is global state independent of newbus attach status. After the failed attach the bus/sim/paths remain fully resolvable; CAM's own boot-time scan (and anything else that compiles a path to that bus) reaches dpt_action → dptexecuteccb, which pokes dpt_outb() through dpt->tag/bsh — a bus_space handle to an rman record that was just released (or, with DF-2151's wrong-rid no-op, leaked). Cross-device register corruption on x86 PIO; MMIO variant touches the re-mapped page owner.
2. Unkillable I/O. No interrupt handler was installed, so nothing the HBA completes is ever reaped — every command routed to the phantom bus hangs in CAM forever (boot-time wedging of the SCSI scan path).
3. Shutdown-time use of released state. dptshutdown (dpt_scsi.c:1717-1733) still fires on every reboot and issues dpt_send_immediate through the released/leaked register window.
4. Permanent leak of the CCB DMA memory, sg maps, three child DMA tags, io (via the DF-2151 no-op) — and see DF-5154 for parent_dmat, which is additionally never destroyed even where dpt_free is called.

No kernel-heap corruption primitive is in scope here (bus-space logical UAF plus leak), and the trigger is hardware/boot-time — there is no unprivileged trigger and no uid=0 route; the class does not permit one.

Reproduction status

untested — hardware-gated. Verified on the audit guest (pciconf -l → no vendor 0x1044 device; see env.txt): the entry path cannot fire there, and the defect is not driveable by any userland program (absent the card). Line-level proof of the unwind gap is in VERDICT.md. Family precedent: DF-5115 (ips, same shape) was filed untested for the same reason; DF-5141 (mlx) was reproduced only because its primitive was a genuine double-kfree driveable by a KLD harness — this one has no such primitive to harness.

Fix

See fix.diff: full reverse-order teardown on the bus_setup_intr failure path (free paths → deregister buses → free sims → deregister the shutdown handler (tag now stored in the softc) → dpt_free → destroy parent_dmat), plus the correct io rid in bad: (that hunk overlaps DF-2151's fix and is included only because the unwind is meaningless while the release is a no-op).

DF-5153 VERDICT — dpt_pci.c setup_intr-failure incomplete unwind

Status: untested (hardware-gated). Impact: none demonstrable on the audit guest (no DPT controller present — verified, env.txt). Confidence: certain that the defect exists as described (line-proven). Fix: authored, not kernel-validated (fix.diff; baseline behavior cannot be reproduced without the HBA, so fix validation is not_testable).

1. Root cause (line-certain)

• sys/dev/raid/dpt/dpt_pci.c:151 — dpt_init(dpt) succeeds (DMA tags at dpt_scsi.c:1235/1356/1370, CCB array at :1385, sg maps at :1254).
• sys/dev/raid/dpt/dpt_pci.c:159 — dpt_attach(dpt) registers up to 3 SIMs + wildcard paths with XPT and the shutdown_post_sync handler (dpt_scsi.c:1466-1488); return value (channel count) is ignored by the glue — harmless here since >0 channels means live registrations either way.
• sys/dev/raid/dpt/dpt_pci.c:163-169 — bus_setup_intr failure jumps to bad: having undone nothing of the above.
• sys/dev/raid/dpt/dpt_pci.c:173-179 — bad: releases only io/irq. The io release passes rid 0 for a resource allocated at rid PCIR_MAPS(=0x10)/PCIR_MAPS+4 → pci_release_resource' resource_list_delete(rl, type, rid) lookup misses → EINVAL no-op → the io leaks (this half is DF-2151, known). The irq release at :176-177 uses rid 0, which matches the allocation rid at :103-105 → genuinely released while the device keeps its registers programmed (busmaster was forced on at :113-114).
• sys/kern/subr_bus.c:3328-3333 — bus_release_resource is a pure rid-keyed dispatch, confirming the asymmetry.

2. What stays alive (the defect)

3. Reachability / threat model

Entry requires dpt_pci_probe to match PCI 0x1044:0xa400 (dpt_pci.c:61-66) — real DPT SmartRAID hardware — and bus_setup_intr to fail (interrupt vector exhaustion, MSI/MSI-X setup failure on the platform). Both are boot/kldload-time conditions. No unprivileged local user trigger exists; on hardware without the card the driver never attaches (verified on the guest: pciconf -l shows no 0x1044 device). uid=0 escalation is not applicable: no user-controlled grooming window, no kernel-heap primitive — the residual primitives are (a) a CAM-reachable bus_space handle whose rman record was released/re-allocatable, (b) an irq released under a busmaster-enabled device, (c) permanent leaks, (d) never-completing CAM commands (boot hang). Ceiling on real hardware: cross-device PIO/MMIO corruption and boot-time DoS.

4. Why untested (honest classification)

• Guest has no DPT HBA (env.txt) → dpt_pci_attach unreachable, and no userland program can reach any part of this path even with one present.
• Unlike DF-5141 (mlx double-free — reproduced via KLD harness driving the real mlx_free() twice), the consequence here is logical (CAM/rman lifetime), not allocator-detectable: a harness that fabricates a softc and calls xpt_bus_register + bus_release_resource would only demonstrate that CAM keeps a sim whose resource was released — the code's own text — without adding evidentiary weight. Recorded as analysis-verified instead.

5. Fix

fix.diff (dpt_pci.c + dpt.h + dpt_scsi.c): reverse-order teardown on the failure branch — free paths, deregister buses, free sims, deregister the shutdown handler via a tag now stored in the softc, crit_enter; dpt_free(dpt); crit_exit(); bus_dma_tag_destroy(dpt->parent_dmat) (covers DF-5154 on this path); and the io rid correction in bad: (hunk shared with DF-2151's fix). Not kernel-build-validated (no target hardware; fix validation not_testable).

6. Kernel references

sys/dev/raid/dpt/dpt_pci.c:159, :163-169, :173-179, :88-94, :103-105, :113-114; sys/dev/raid/dpt/dpt_scsi.c:1165, :1235, :1356, :1370, :1385, :1466-1488, :1717-1733; sys/kern/subr_bus.c:3328-3333.

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.