DF-5042 — VERDICT

Verdict: REPRODUCED (runtime, verbatim driver code, no hardware required for the replay) Class: resource leak / improper error handling (CWE-404/755) Impact ceiling: none (kernel kmem leak per failed attach; unbounded across attach retries) Confidence: certain

Reproduction

The guest has no AdvanSys HBA (no vendor 0x10CD device; pciconf -lv), and adv_pci.c is not even built on X86_64_GENERIC (device adv0 at isa registers a pci/adv module id but no hardware ever probes). The finding is therefore hardware-gated for the natural trigger, but the failure unwinds themselves were replayed at runtime on the guest by compiling the four driver translation units verbatim into a kld and driving the real adv_pci_attach() with a scripted chip (see README.md). This is the same technique the DF-4964 pack used for sili.

Two scenarios, both observed in run.log (fresh clean-source guest, kernel 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 2026):

• mode INITFAIL — the real adv_init() runs against the scripted chip (signature present, CHIP_STATUS never sets ADV_CSW_HALTED), fails exactly at advansys.c:794-798 ("adv0: Unable to halt adapter. Initializationfailed"), and the adv_pci.c:260-264 unwind executes. Observation: bus_dma_tag_destroy calls for the parent_dmat: 0 — adv_free(adv) ran switch(1) which enters at case 1 (kfree ccb_infos — NULL) and never reaches case 2 (destroy parent_dmat). *** DF-5042 LEAK PROVEN ***.

• mode IRQFAIL — fk_adv_init scripts success so attach reaches the IRQ stage; bus_alloc_resource(SYS_RES_IRQ) succeeds (fake resource), bus_setup_intr is scripted to fail; the adv_pci.c:289-294 unwind executes. Observations: parent_dmat destroy 0 (DF-5042) and bus_release_resource for the IRQ resource 0 (DF-5043, filed separately); only the IOPORT resource is released.

Mechanism (source-confirmed)

• adv_pci.c:184 creates adv->parent_dmat; adv_pci.c:202 then does adv->init_level++ → init_level == 1.
• adv_free() (advansys.c:747-776) is a fall-through switch where case 1 = kfree(ccb_infos) and case 2 = bus_dma_tag_destroy(parent_dmat); the tiers 2..6 belong to adv_attach()'s own creations (advansys.c:1298,1339,1352,1360,1368). With init_level == 1 the unwind starts at case 1 and skips case 2 — parent_dmat is never destroyed.
• The two overrun-allocation failure paths already work around exactly this by destroying adv->parent_dmat manually (adv_pci.c:212, adv_pci.c:222) — proof of intent — but the adv_init()-failure path (adv_pci.c:260-264) and the IRQ-setup-failure path (adv_pci.c:289-294) lack the manual destroy.
• Every failed attach therefore leaks one bus_dma_tag_t (plus, on the IRQ path, the active IRQ resource — DF-5043). device_doattach() (sys/kern/subr_bus.c:2115-2124) drops the driver on attach failure without running any detach, so nothing else ever releases the tag; hotplug/rescan retries accumulate the leak.

Fix validation (runtime A/B, no kernel rebuild needed)

fix.diff adds the missing explicit bus_dma_tag_destroy(adv->parent_dmat) (and, on the IRQ path, bus_release_resource(SYS_RES_IRQ) — the DF-5043 half) to both unwinds, mirroring the file's own overrun-path idiom. Rebuilding the kld against the patched adv_pci.c and replaying both modes (run.2.log):

DF5042: bus_dma_tag_destroy: parent=1 overrun=0
DF5042: bus_release_resource: IOPORT=1 IRQ=1
DF5042: unwind clean (fix effective?)

Baseline leaks → patched clean, same driver code otherwise. fix.diff is git apply --check clean against the audited tree.

Gating precondition (natural trigger)

AdvanSys ASC1200A/1200B/3000 PCI SCSI HBA (vendor 0x10CD) or VFIO-assigned endpoint that probes, passes the signature check, and then fails adv_init()/bus_setup_intr() — e.g. a wedged/missing chip behind a decoding BAR, or IRQ exhaustion. Root-relevant only as availability/kmem hygiene; no escalation path (leaked tag contains no user data).

Exploit chain

Not applicable — bounded-impact kmem leak per failed attach; no corruption, no info disclosure. The leak primitive is a bus_dma_tag_t (+ embedded segment array) per failed attach, repeatable with device re-probe loops.

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.