DF-4591 / trigger.sh
#!/bin/sh # DF-4591 trigger โ tws(4) attach-failure resource leaks (MSI + memory + DMA) # # VULNERABILITY: sys/dev/raid/tws/tws.c:309-341 โ the attach-failure unwinds # (attach_fail_4/3/1) release only the cdev, the IRQ resource and the BARs; # they never release: # - the MSI allocation made at tws.c:426 (pci_alloc_1intr) โ # pci_release_msi() is called only in tws_detach (tws.c:381-382); # - sc->reqs (tws.c:535), sc->sense_bufs (:537), sc->scan_ccb (:539), # sc->aen_q.q (:580), sc->trace_q.q (allocated in tws_attach at :202, # leaked even by the earliest attach_fail_1 failure); # - the per-request dma maps created in tws_init_reqs (:610) and the # cmd dma map / dma_mem (:499-509) and the three bus_dma tags # (:465-530). # # TRIGGER RECIPE (requires a 3ware 9700-series controller that FAILS to # initialize, e.g. wedged firmware โ cf. DF-1924/DF-1925 hardware spins): # 1. kldload tws.ko with the controller present but not ready # (tws_ctlr_reset() fails -> tws_init() returns FAILURE at # tws.c:541-543 -> attach_fail_4). # dmesg: "tws0: <...>: init failure" style messages, then ENXIO. # 2. Observe the leak: # vmstat -m | grep twsbuf (reqs+sense+aen+trace stay allocated) # (MSI vector leak: subsequent kldload cycles fall back to INTx or # exhaust the MSI pool โ compare `devinfo -v` / pciconf -vc bars.) # 3. EXPECTED (vulnerable): every failed (re)load leaks ~200 KB of # M_TWS kernel memory + dma maps + 1 MSI vector, permanently. # PATCHED (fix.diff): failed attach frees everything; repeated # load/fail cycles are allocation-neutral. # # On the audit QEMU guest there is no 13C1:1010 controller, so this script # only records the hardware absence (see run.log). set -e echo "== guest ==" uname -a if pciconf -l 2>/dev/null | grep -q "13c1"; then echo "3ware controller present โ run the recipe above as root." else echo "NO 3ware controller (vendor 0x13C1) on this guest โ hardware-gated." kldload tws 2>&1 || true dmesg | grep -i tws | tail -2 || true fi |