⬢ DragonFlyBSD Kernel Audit
DF-5464 / run.log
← back to finding ↓ download raw
# DF-5464 baseline runs (X86_64_NOINV = X86_64_GENERIC minus INVARIANTS,
# i.e. stock-GENERIC production behaviour; built on the guest with
# make -j6 nativekernel KERNCONF=X86_64_NOINV).
#
# RUN 1 (safe canary, icu_msiabi_probe.ko) -- guest healthy afterwards:
icu_msiabi_probe: loaded
icu_msiabi_probe: msix_alloc(cpu0) rc=0 irq=16
icu_msiabi_probe: msi_map addr=0xfee00000 data=0x30
icu_msiabi_probe: msix_release done
icu_msiabi_probe: calling ICU msi_alloc(count=64, cpu0) (contract max is 32)
icu_msiabi_probe: msi_alloc rc=0
icu_msiabi_probe: zone[0..7] = 128 129 130 131 132 133 134 135 (allocated block)
icu_msiabi_probe: 32/96 canary words past zone[31] overwritten (32 expected for a 64-count alloc)
icu_msiabi_probe:   zone[32]=160  <-- OOB write past 32-int contract
icu_msiabi_probe: msi_release(64) done
icu_msiabi_probe: SAFE PHASE COMPLETE
#   -> count=64 accepted with rc=0; 32 ints written past the caller's
#      32-int contract array (in the real caller: 'int irqs[32]' on the
#      kernel stack, sys/bus/pci/pci.c:1952). Legal msix(count=1) path
#      still works -> not a blanket failure.
#
# RUN 2 (icu_msiabi_neg.ko, count=-2600000):
icu_msiabi_neg: calling ICU msi_alloc(count=-2600000, cpu0): expect kernel page fault on icu_irqmaps[0][-2600000] (icu_abi.c:476)
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic id = 0
fault virtual address	= 0xffffffff7f1bf020     (below KERNBASE 0xffffffff80200000)
fault code		= supervisor read data, page not present
instruction pointer	= 0x8:0xffffffff80b9c1ba
Stopped at      icu_abi_msi_alloc_intern+0x5a:  movl    (%r13,%rax,1),%edi
db>
#   -> negative count walks the scan index below the kernel image: OOB
#      read fault at the im_type load (icu_abi.c:476). Panic.
#
# RUN 3 (icu_msiabi_livelock.ko, count=0):
login: icu_msiabi_livelock: calling ICU msi_alloc(count=0, cpu0): expect infinite loop at icu_abi.c:473 holding icu_irqmap_tok -- kldload will not return
#   -> kldload never returned (caller-side timeout expired, no exit code);
#      afterwards the guest stopped servicing NEW ssh sessions entirely
#      ("Connection timed out during banner exchange" for >2 minutes on
#      every attempt) -- system-wide wedge, not just a busy cpu.
#      Hardware reset (QEMU monitor system_reset) required to recover.