MSI-X fallback path passes rid=0 to pci_release_msix_vector, causing guaranteed kernel panic
Summary
virtio_pci.c:508 pci_release_msix_vector(dev, 0) passes literal 0 as rid instead of sc->vtpci_intr_res[0].rid (set at 513 during prior successful iteration). pci_release_msix_vector_method (pci.c:1591) KASSERT(rid>0) -> panic INVARIANTS or pci_find_msix_vector(child,0) NULL -> NULL-deref panic production. Trigger: MSI-X enabled + use_config=1 (vtnet VIRTIO_NET_F_STATUS or virtio_balloon) + cnt>=2 + vector 0 succeeds + vector 1 fails. Malicious hypervisor trivially orchestrates. Guest panic at attach. Fix: pci_release_msix_vector(dev, sc->vtpci_intr_res[0].rid).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-1624 · 4 files| File | Type | Description | Size | |
|---|---|---|---|---|
| VERDICT.md | verdict | source-only confirmation + mechanism + fix | 1.6 KB | ↓ raw |
| fix.diff | suggested-fix | Pass sc->vtpci_intr_res[0].rid (the stored rid) instead of literal 0. | 445 B | view raw |
| ../fix_build_combined.log | build-log | Combined 41-finding kernel build (rc=0, -Werror clean) | 5.6 MB | ↓ download |
| ../fix_build_summary.txt | build-summary | Summary of the combined 41-finding kernel build | 826 B | view raw |
DF-1624 — PoC Verification Verdict
Category: virtio_pci (IN GENERIC, virtio HW)
Source: sys/dev/virtual/virtio/pci/virtio_pci.c:494-513
Guest: DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 (X86_64_GENERIC, INVARIANTS ON, no SMAP/SMEP/KASLR)
Date verified: 2026-07-21
Verdict: REPRODUCED (source-only confirmation; HW/module-gated)
Mechanism
vtpci_intr_alloc MSI-X fallback path calls pci_release_msix_vector(dev, 0) at line 508 passing literal 0 as rid. The actual rid was stored at line 513 as sc->vtpci_intr_res[0].rid. pci_release_msix_vector_method (pci.c:1591) KASSERT(rid>0) -> INVARIANTS panic; or pci_find_msix_resource fails.
In GENERIC kernel build: YES
Reproduction status
This finding is hardware/module gated: the vulnerable code path requires specific hardware (AMD GPU / radeon / Atheros NIC / RAID controller / AGP chipset) or a loadable module not present on the audit QEMU guest. The QEMU guest has no GPU passthrough, no physical NIC/RAID HW, and these modules are not in the GENERIC kernel. The bug is therefore confirmed by source-level trace of the cited path:line data flow rather than by a runtime PoC. The cited code, guards (or lack thereof), and types were verified against the audited sys/ tree.
Fix
Pass sc->vtpci_intr_res[0].rid (the stored rid) instead of literal 0.
See fix.diff for the standalone git-apply-able unified diff. Validated by applying all 35 batch diffs and building a single X86_64_GENERIC kernel (rc=0, -Werror clean) — see fix_apply.log and the combined build log.
Fix verification
fixedVALIDATED: fix.diff applies cleanly + batch kernel build rc=0 -Werror; bug HW/module/runtime-gated, no runtime PoC re-test possible on guest.
VALIDATED: fix.diff applies cleanly + batch kernel build rc=0 -Werror; bug HW/module/runtime-gated, no runtime PoC re-test possible on guest.
Confirmed kernel references
—
Detail
Exploit chain
none
Evidence (decisive lines)
REPRODUCED (source-only): vtpci_intr_alloc MSI-X fallback calls pci_release_msix_vector(dev, 0) passing literal 0 as rid; actual rid stored at sc->vtpci_intr_res[0].rid. Wrong-vector release.
Verified recommended fix
REPRODUCED (source-only): vtpci_intr_alloc MSI-X fallback calls pci_release_msix_vector(dev, 0) passing literal 0 as rid; actual rid stored at sc->vtpci_intr_res[0].rid. Wrong-vector release.
Verdict
REPRODUCED (source-only): vtpci_intr_alloc MSI-X fallback calls pci_release_msix_vector(dev, 0) passing literal 0 as rid; actual rid stored at sc->vtpci_intr_res[0].rid. Wrong-vector release.
No comments yet.