# Guest environment & hardware-gate proof (shared across DF-2488..2512, 2217, 2414..2419) uname: DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 x86_64 kernel config: X86_64_GENERIC (build #0, unpatched audit-source) compiler: gcc 8.3 (in-guest), kernel built with -Werror ## PCI inventory (pciconf -l) — what is and is NOT present - hostb0@0:0:0 class=0x060000 (i440FX host bridge) - isab1@0:1:0 class=0x060100 (PIIX3 ISA bridge) - atapci0@0:1:1 class=0x010180 (Intel 82371SB PIIX3 IDE, WDMA2) <-- the ONLY ATA controller - none0@0:1:3 class=0x068000 (PIIX3 PMU) - vgapci0@0:2:0 class=0x030000 (QEMU std VGA) - virtio_pci0@0:3:0 class=0x020000 (virtio-net = vtnet0) - virtio_pci1@0:4:0 class=0x010000 (virtio-blk = vbd0, the root disk) ABSENT (the gates): - NO NVMe controller (class 0x0108 never appears) -> DF-2217/2511/2512 - NO AHCI controller (class 0x0106 never appears; atapci0 is 0x010180 IDE, not AHCI) -> DF-2492/2510 (need AHCI w/>8 ports), DF-2418/2419 (need AHCI) - NO AdvanSys HBA (no adv/adw PCI ID) -> DF-2414/2417 - NO nata ATA disk (no /dev/ad*, no /dev/ada*) -> DF-2488 (ad_describe) - NO ataraid volume (no /dev/ar*, nataraid attaches nothing) -> DF-2493 - NO ATAPI floppy (no /dev/afd*) -> DF-2507 - NO ATAPI tape (no /dev/ast*) -> DF-2509 ## Loaded kernel modules (kldstat) kernel, ehci.ko, xhci.ko (NO nata/nvme/advansys/ahci module loaded as kld) ## Driver attachment (corrects the batch's "no nata" premise) There is NO sys/dev/disk/ata/ (new ata(4)) in this source tree; nata is the ONLY ATA stack. nata/chipsets/ata-intel.c:51 matches PIIX3 ("ATA_I82371SB ... PIIX3"), so nata IS compiled into GENERIC and DOES drive atapci0 -> ata0/ata1 -> acd0 (the QEMU DVD-ROM). natapicam bridges acd0 to CAM as cd0/pass0/sg0 (scbus1). => The nata-atapi cluster (DF-2490/2499/2500/2503/2506) is NOT gated by "no nata"; nata is present and attached to acd0. Their REAL gates are trigger/credential preconditions (see each VERDICT.md), not absent hardware. ## Device-node access on this guest (closes the unprivileged surface) /dev/acd0 crw-r----- root:operator (operator group = root ONLY; maxx not operator) /dev/cd0 crw-r----- root:operator /dev/pass0 crw------- root:operator (root-only) /dev/sg0 crw------- root:operator (root-only) operator:*:5:root (maxx uid 1001 is NOT in operator) => an unprivileged user cannot open acd0/cd0/pass0/sg0. Empirically, even after adding maxx to operator, open("/dev/acd0") returns EPERM before the ioctl handler runs; root itself gets EINVAL (no media -> TEST_UNIT_READY fails). So the atapi-cd TOCTOU copyout (DF-2503/2506) cannot be exercised here. ## camcontrol devlist at scbus1 target 0 lun 0 (sg0,pass0,cd0) ## atacontrol / nvd atacontrol: not found (nata userland tool absent) nvd: not found (no NVMe userland/driver) ## Conclusion Every cited vulnerable CODE PATH in this batch exists in sys/ and is compiled into the GENERIC kernel, but it is NOT exercisable at runtime on this guest because the required HBA/device/trigger is absent (or, for the 5 nata-atapi findings, the device is a benign read-only DVD-ROM gated behind operator/root and the specific malicious-device / hot-unplug / burner / winning-race trigger is not present). Each finding's VERDICT.md states the precise gate; each bug is confirmed REAL in source and carries a defense-in-depth fix.diff that applies (git apply --check) and compiles (full X86_64_GENERIC build, rc=0, -Werror).