⬢ DragonFlyBSD Kernel Audit
DF-5082 / verdict.json
← back to finding ↓ download raw 
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
{
  "finding_id": "DF-5082",
  "status": "reproduced",
  "verdict": "REPRODUCED at source+harness on the audit guest (DF-4764 fidelity class): a KLD carrying a VERBATIM copy of hptrr_os_bsd.c:85-106 (rename-only) with the REAL HBA/pcibar layout from <dev/raid/hptrr/os_bsd.h> (CTASSERT-proven) calls it against a real PCI device (hostb0, rid 0x10, BAR register reads 0) through the real newbus/pci/rman stack; bus_alloc_resource_any() returns NULL exactly as in production for an unassignable BAR (pci_add_map() adds no resource-list entry for a zero BAR, sys/bus/pci/pci.c:2525, so resource_list_alloc() takes its !rle->0 path, sys/kern/subr_bus.c:2673), and the verbatim copy dies with Fatal trap 12: page fault, fault virtual address 0x40 == offsetof(struct resource, r_virtual), Stopped at df5082_trigger+0x2de: movq 0x40(%rax),%rsi - the inlined rman_get_virtual(NULL) of hptrr_os_bsd.c:104; ssh returned RC=124 and the guest sat at db>. In production the detonator is hptrr device attach (driver compiled into X86_64_GENERIC, sys/config/X86_64_GENERIC:120) on a RocketRAID 17xx/2xxx card whose BAR cannot be allocated (unassigned BAR / ioport-memory conflict) -> persistent boot panic; not reachable by an unprivileged local user. Fix guard validated A/B in the same boot: the fix.diff variant survived the identical NULL allocation twice (guarded, no panic) before the verbatim run panicked. Impact ceiling: probe/attach DoS; the primitive is a fixed near-NULL read, no escalation path.",
  "reproduced": true,
  "impact": "panic",
  "confidence": "certain",
  "exploit_chain": "",
  "evidence": "panic.txt: fault virtual address = 0x40 + Stopped at df5082_trigger+0x2de: movq 0x40(%rax),%rsi (verbatim-copy panic); run.log + run.2.log: DF5082-fixed: bus_alloc_resource_any(rid 0x10) returned NULL; guarded, no panic (fix A/B, same victim hostb0/rid 0x10); VERDICT.md: full trace hptrr_os_bsd.c:101->104, rman.h:149 macro, 0x40 offset derivation; build.log: clean KLD build with CTASSERT layout proofs",
  "kernel_refs": [
    "sys/dev/raid/hptrr/hptrr_os_bsd.c:101",
    "sys/dev/raid/hptrr/hptrr_os_bsd.c:104",
    "sys/sys/rman.h:149",
    "sys/sys/rman.h:106",
    "sys/kern/subr_bus.c:2673",
    "sys/bus/pci/pci.c:2525",
    "sys/config/X86_64_GENERIC:120"
  ],
  "poc_changes": "no seed; harness authored for this finding: verbatim copy of os_map_pci_bar renamed df5082_os_map_pci_bar_copy/fixed (static, avoids clash with the kernel-resident hptrr_os_map_pci_bar), real-header HBA via os_bsd.h (needed SRCS+= device_if.h bus_if.h pci_if.h and an empty opt_cam.h in the kmod Makefile), victim = first PCI child with a BAR reading 0",
  "attempts": 3,
  "guest_uname": "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",
  "runtime_sec": 1500,
  "guest_dirty": 1,
  "build_cmd": "vm.sh run_root sh /root/build.sh   (kmod.mk build in /root/df5082, cc 8.3 [DragonFly])",
  "run_cmd": "vm.sh run_root kldload /root/df5082/df5082.ko; sysctl df5082.trigger=2; sysctl df5082.trigger=1",
  "code_hash": "c1fa49fa1d604c52432c93f2b9626e54177da3b6b8d9f7d3ee57d3767e7b6392",
  "notes": "guest was reset with-src after the panic and is up/clean; hardware gate: no HighPoint 0x1103 device on the guest, so the in-tree attach path itself is unexercisable - same class as accepted DF-4764 source+harness precedent but strictly stronger than the DF-5039 twin (which stayed untested). The 0 -> 0 echo in run.log is a sysctl(8) display quirk; the handler demonstrably received the value (fixed branch taken both times, dmesg in run.2.log).",
  "recommended_fix": "NULL-check bus_alloc_resource_any() in os_map_pci_bar() and return 0 on failure; guard os_unmap_pci_bar() against res==NULL/base==0 entries (fix.diff)",
  "fix_status": "fixed",
  "fix_baseline_reproduced": 1,
  "fix_patched_reproduced": 0,
  "fix_verdict": "fix.diff guard validated in-harness A/B: same boot, same victim (hostb0, rid 0x10), same NULL allocation - fixed variant printed guarded, no panic twice and the guest survived (run.log, run.2.log); the verbatim copy then panicked at VA 0x40 (panic.txt). Full-kernel rebuild validation not performed: the in-tree attach path requires HighPoint hardware; the guard is exercised exactly at the NULL allocation.",
  "fix_evidence": "run.2.log (fixed variant survives, dmesg capture), panic.txt (baseline panic), fix.diff (the exact guard applied to df5082_os_map_pci_bar_fixed)"
}