⬢ DragonFlyBSD Kernel Audit
DF-4929 / panic.2.txt
← back to finding ↓ download raw
DF-4929 run 2 serial-console evidence (captured from dfbsd-qemu/boot.log immediately
after the run, before the post-run `vm.sh reset with-src`; run 1's identical panic
is preserved verbatim in panic.txt).

Kernel-side dmesg lines (boot.log:202-206):
  uafsim: loaded; write >=10 bytes to /dev/uafsim0 then sysctl hw.uafsim_detach=1
  uafsim: [detach] lockstatus(dev_lock)=8 (1 == LK_EXCLUSIVE held by writer)
  uafsim: [detach] calling stock tpm20_release() with dev_lock HELD elsewhere
  uafsim: [detach] tpm20_release() returned; lockuninit assert did NOT fire
  uafsim: [detach] softc freed + sprayed; writer still asleep inside transmit

Userland (run.2.log): writer later printed "WRITER DONE rc=0" — the writer thread
ran the whole tail of stock tpm20_write (callout_reset, owner_tid store,
LK_RELEASE) against the FREED softc and survived silently.

~500ms after the writer armed the discard callout (tpm20.c:138-139):

  Fatal trap 12: page fault while in kernel mode
  cpuid = 5; lapic id = 5
  fault virtual address	= 0x48
  fault code		= supervisor read data, page not present
  instruction pointer	= 0x8:0xffffffff8068d270
  stack pointer	        = 0x10:0xfffff800898e4968
  frame pointer	        = 0x10:0xfffff800898e49d0
  code segment		= base 0x0, limit 0xfffff, type 0x1b
  			= DPL 0, pres 1, long 0, def32 0, gran 1
  processor eflags	= interrupt enabled, resume, IOPL = 0
  current process	= Idle
  current thread        = pri 12
  kernel: type 12 trap, code=0

  CPU5 stopping CPUs: 0x0000001f
   stopped
  Stopped at      device_print_prettyname:        movq    0x48(%rdi),%rax
  db>

Interpretation: the stock tpm20_discard_buffer callout fired into the FREED
softc (callout context => current process Idle) and dereferenced
sc->dev (device_printf(sc->dev, ...) tpm20.c:164) read from freed memory.
The fault virtual address 0x48 = offset of the first field dereferenced by
device_print_prettyname(dev) with a NULL dev, i.e. the freed chunk still
carried the softc's stale/zeroed content — the callout was executing on
memory that no longer belongs to the driver. Two runs, two identical panics.