# VERDICT — DF-4402

**Status: inconclusive (hardware-gated attach path).**

## Proof

1. `tws_cam_attach` (`tws_cam.c:167-175`):
   ```c
   sc->sim = cam_sim_alloc(tws_action, tws_poll, "tws", sc, ..., devq);
   cam_simq_release(devq);
   if (sc->sim == NULL) {
       tws_log(sc, CAM_SIM_ALLOC);
   }                       /* no return! */
   ```
2. Execution continues to `xpt_bus_register(sc->sim, 0)` (`:178`) with
   `sc->sim == NULL`. `xpt_bus_register` (`sys/bus/cam/cam_xpt.c:4298-4306`)
   first executes `sim_lock_assert_owned(sim->lock)` — a NULL deref read on
   INVARIANTS builds — and unconditionally `sim->bus_id = bus` (`:4306`) — a
   NULL-pointer **write** on production builds. Kernel panic at attach.
3. Asymmetry evidence: the bus-register failure path knows the correct
   pattern — `cam_sim_free(sc->sim); sc->sim = NULL;` (`:179-180`) — while the
   create-path failure path (`:188-190`) and bus-scan failure path (`:194-198`)
   omit it, leaving `sc->sim` dangling/registered respectively.
4. `tws_cam_detach` (`:204-216`) calls `xpt_bus_deregister(cam_sim_path(sc->sim))`
   and `cam_sim_free(sc->sim)` guarded only by `if (sc->sim)` — a stale
   non-NULL pointer double-frees.

## Trigger
Boot or kldload the driver when kernel memory is exhausted enough for
`cam_sim_alloc` (kmalloc of `struct cam_sim`) to fail. Not reproducible on the
audit guest (no 3ware PCI device → probe never succeeds).

## Impact ceiling
Panic at attach (DoS); latent double-free in detach if any future caller invokes
`tws_cam_detach` after a partially-failed attach. Severity Low (requires
allocation failure at attach; boot-time/privileged context).

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