# VERDICT — DF-4969

**Status: untested** — the AdvanSys driver is compiled into the guest's default kernel
(`sys/config/X86_64_GENERIC:101`) but the guest has **no PCI device with an AdvanSys
vendor ID (0x10CD)** (`pciconf -l`, env.txt), so `adw_pci_probe` never matches,
`adw_pci_attach` never runs, and no runtime trigger exists on this guest. The defect is
**certain by code inspection**; the cited lines were printed verbatim from the guest's
`/usr/src` by `adw_static_check.sh` (run.log).

## The defect, path by path

Resource acquisition in `sys/dev/disk/advansys/adw_pci.c`:

1. `:211-225` — `regs = bus_alloc_resource(dev, regs_type, &regs_id, ...)` (active BAR
   resource owned by the driver).
2. `:227-229` — `adw = adw_alloc(dev, regs, regs_type, regs_id)` — `adwcam.c:818-838`
   kmallocs the softc (`M_INTWAIT`, cannot fail) and stores `regs` in it.
3. `:291-298` — `adw->irq = bus_alloc_resource(dev, SYS_RES_IRQ, ...)`.

Error unwinds after that:

4. `:235-238` signature failure → `adw_free(adw); return ENXIO`.
5. `:242-245` **`entry->setup()` failure → bare `return (error)` — no `adw_free`, no
   release** (latent: both in-tree setups return 0 unconditionally today, but the path
   is live code for any future setup that can fail).
6. `:265-270` dma-tag failure, `:274-278` `adw_init` failure, `:295-298` IRQ-alloc
   failure, `:300-303` `adw_attach` failure → all call only `adw_free(adw)`.

`adw_free` (`adwcam.c:844-886`) unwinds the DMA hierarchy by `init_level` and kfrees
`adw->name`/`adw` — it contains **no** `bus_release_resource` for `regs`/`irq` and no
`bus_teardown_intr` (nothing in the driver ever calls either). Newbus does not
auto-release driver resources on failed attach, so:

- every failure path above leaks the active BAR resource permanently (and the IRQ
  resource once reached), and
- path 5 additionally leaks the kmalloc'd softc + name.

Practical impact: with AdvanSys hardware present, any attach failure (bad signature,
wedge → `adw_init_chip` ENXIO (`adwcam.c:1136-1137`), tag/IRQ allocation failure,
`bus_setup_intr` failure) permanently consumes the card's register resource; re-probing
(_driver re-register_, kldload-style cycles) stacks one leaked resource per attempt.
Resource leak only — no UAF is reachable today:

- the `adw_attach` steps after `bus_setup_intr` (`adwcam.c:1163-1180`) cannot fail
  (`cam_sim_alloc` is `M_INTWAIT`, `cam_sim.c:160-190`; `xpt_bus_register` returns
  `CAM_SUCCESS` unconditionally, `cam_xpt.c:1493+`), so the handler is never left hooked
  into a freed softc;
- `bus_dma_tag_destroy(adw->parent_dmat)` with the pre-incremented `init_level`
  (`adw_pci.c:263-272`) is NULL-safe (`busdma_machdep.c:334-337`).

Distinct from DF-4309 (per-ACB dma-map leak in `adw_free`): this finding is the
**bus resource** side (`regs`/`irq` never released, setup-path softc leak).

## Fix

`fix.diff`: release the acquired resources on every error path in `adw_pci_attach`
(regs via the locals; irq via `adw->irq` before `adw_free`), and add the missing
`adw_free(adw)` on the setup-failure path.

## Fix validation

Not testable on this guest (no AdvanSys hardware — probe never matches).

## 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.