⬢ DragonFlyBSD Kernel Audit
DF-5477 / 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-5477",
  "status": "reproduced",
  "reproduced": true,
  "impact": "panic",
  "confidence": "certain",
  "verdict": "efi_get_table() stores the firmware-fed st_cfgtbl (a PHYSICAL address \u2014 this kernel never calls SetVirtualAddressMap, rt_setvirtual has zero call sites) as a raw kernel-virtual pointer (efirt.c:411-412) and walks it outside the 1:1 efi pmap with an unbounded firmware-fed st_entries count (efirt.c:477-485). Verified on the audit guest via a verbatim-copy KLD harness (the BIOS-boot rig cannot populate the production statics): the unbounded walk consumed an entry 4776 bytes past the tables true extent and returned a kernel DMAP pointer (0xffffc5eadbeef000) to the caller; and dereferencing a realistic physical cfgtbl address (0x7FB1C000) as KVA produced exactly the predicted fatal kernel fault (trap 12, Fatal user address access from kernel mode, stopped at bcmp+0x11 \u2014 the efirt.c:480 dereference). On any conforming EFI boot the first root-only EFIIOC_GET_TABLE ioctl deterministically panics the kernel; on mapped/crafted variants it is an arbitrary-length OOB read walk that leaks kernel DMAP VAs. Firmware/loader-fed at boot, root-gated at runtime \u2014 no unprivileged route; family: unvalidated firmware table (DF-5365/DF-5430-5433 class).",
  "exploit_chain": "",
  "evidence": "run.log: DF-5477A: FOUND entry 199 past table end -> returned kernel DMAP pointer 0xffffc5eadbeef000; run.2.log/panic.txt: Fatal user address access from kernel mode from sysctl, Fatal trap 12: page fault while in kernel mode, fault virtual address = 0x7fb1c000, Stopped at bcmp+0x11: movq (%rdi),%r8; fix_run.log: fixed code returns EOVERFLOW for the st_entries lie and DMAP-translates 0x7fb1c000 before deref, no fault.",
  "kernel_refs": [
    "sys/platform/pc64/x86_64/efirt.c:411",
    "sys/platform/pc64/x86_64/efirt.c:477",
    "sys/platform/pc64/x86_64/efirt.c:480",
    "sys/platform/pc64/x86_64/efirt.c:481",
    "sys/dev/misc/efirt/efidev.c:77",
    "sys/platform/pc64/x86_64/trap.c:917",
    "stand/boot/efi/loader/bootinfo.c:397"
  ],
  "poc_changes": "No seed existed. Harness authored from scratch: verbatim copy of efi_get_table() (efirt.c:469-487) with only the two statics renamed, driven by module-local crafted tables via sysctl triggers; uuid initializer and include list fixed for DFly kernel-build -Werror; objdir handling (make obj -> /usr/obj/tmp/...).",
  "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": 900,
  "guest_dirty": 0,
  "build_cmd": "cd /tmp/df5477 && printf KMOD=df5477_harness\\nSRCS=df5477_harness.c\\n\\n.include <bsd.kmod.mk>\\n > Makefile && make obj && make",
  "run_cmd": "kldload /usr/obj/tmp/df5477/df5477_harness.ko && sysctl debug.df5477=1   # then sysctl debug.df5477=2 for the panic demo",
  "code_hash": "facb50b210d604f89af59f48012c428a31dfb0cfd28a9943e73177ef2e72852b",
  "notes": "Rig limit: guest boots legacy BIOS \u2014 efi_init() returns ENXIO before assigning efi_systbl/efi_cfgtbl, so the in-situ production function cannot be driven; evidence class is the verbatim-copy KLD harness on the real running kernel (real DMAP layout 0xffffb80000000000, real trap classification). efirt.ko loads on BIOS boots anyway (MOD_LOAD error 6 only logged) and /dev/efi exists (root 0700). Guest was reset via vm.sh reset after the Part-B panic.",
  "recommended_fix": "Cap st_entries (EOVERFLOW beyond 256), translate st_cfgtbl through PHYS_TO_DMAP before the walk, and bounds-check ct_data against the DMAP extent.",
  "fix_status": "fixed",
  "fix_baseline_reproduced": 1,
  "fix_patched_reproduced": 0,
  "fix_verdict": "fix.diff logic applied to the same harness (df5477_fixed.c, built and run on the guest): the st_entries=512 lie is refused with EOVERFLOW (no OOB walk), and the physical cfgtbl address is DMAP-translated (0x7fb1c000 -> 0xffffb8007fb1c000) before dereference with no fault in any case. A full patched-kernel rebuild is not meaningful on this BIOS rig because the vulnerable statics have no inputs here; the harness equivalence is the strongest validation this rig admits.",
  "fix_evidence": "fix_run.log lines: DF-5477A: result error=84 (EOVERFLOW=84) ... FIX HOLDS (walk refused); DF-5477B: ... FIXED code DMAPs it to 0xffffb8007fb1c000 before deref / returned without fault."
}