============================================================
GUEST ENVIRONMENT (DF-1578 verification)
============================================================
$ uname -a
DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026     root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64

$ sysctl -n kern.version
DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026
    root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC

$ cc --version | head -1
cc 8.3 [DragonFly] Release/2019-02-22

============================================================
KERNEL CONFIG — relevant devices
============================================================
$ grep -iE 'hptrr|hpt27xx' sys/config/X86_64_GENERIC
device		"hpt27xx"	# Highpoint RocketRAID 27xx series
device		hptiop		# Highpoint RocketRAID 3xxx series
device		hptmv		# Highpoint RocketRAID 182x
device		hptrr		# Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx

--> hptrr IS compiled into the default X86_64_GENERIC kernel.

============================================================
PCI / SCSI / pass devices at verification time
============================================================
$ pciconf -l | grep -iE 'raid|scsi|sata|hpt'
(empty — no hptrr-class RAID controller detected)

$ dmesg | grep -iE 'hptrr|hpt'
hpt27xx: no controller detected.
(no hptrr attach message — no supported HighPoint RR17xx/22xx/23xx/25xx
controller present)

$ camcontrol devlist
<QEMU QEMU DVD-ROM 2.5+>           at scbus1 target 0 lun 0 (sg0,pass0,cd0)

$ ls -l /dev/pass*
crw-------  1 root  operator   30, 0x00000000 Jul 18 06:42 /dev/pass0

============================================================
SUMMARY
============================================================
* hptrr IS in X86_64_GENERIC (statically compiled in).
* But no HighPoint RR17xx/22xx/23xx/25xx PCI controller is present in
  the QEMU guest, so the driver never attaches (hpt_scsi_io is never
  called; there is no RAID virtual disk to issue CCBs against).
* Even if the driver had attached, the only way to deliver a CCB with
  attacker-controlled dxfer_len is via /dev/passN, which is mode 0600
  root.  No unprivileged path to the vulnerable code exists.