DragonFlyBSD Kernel Audit
DF-0417 / fix_run.log
← back to finding ↓ download raw
panic: rtrequest1_msghandler: rtrequest table req 1, failed on cpu5, error 55
rtrequest1_msghandler() at rtrequest1_msghandler+0x23d 0xffffffff8074cf8d 
rtrequest1_msghandler() at rtrequest1_msghandler+0x23d 0xffffffff8074cf8d 
Stopped at      Debugger+0x7c:  movb    $0,0xbdacf9(%rip)

=== FIX VALIDATION SUMMARY ===
UNPATCHED (#0 with-src)  -- SAME race (ra_race_mt -t 3 -p 8 + ndp -p reader):
  Fatal trap 12: page fault while in kernel mode
  fault virtual address = 0x48
  Stopped at nd6_sysctl_prlist.part.10+0x165: movq 0x48(%rsi),%rdx
  ==> the DF-0417 UAF: dangling pfr->router dereferenced at nd6.c:2248. PANIC.

PATCHED (#1, refcount fix, corrected) -- SAME race:
  No nd6_sysctl_prlist page fault.  No "Fatal trap" attributable to the UAF.
  - First run (3 threads/8pfx): only mbuf-exhaustion warnings; guest wedged
    transiently then RECOVERED to 'up' (no panic signature in boot.log).
  - A *separate* panic can still occur under heavy RA flood:
      panic: rtrequest1_msghandler: rtrequest table req 1, failed on cpu5, error 55
      Stopped at Debugger+0x7c
    This is a DIFFERENT bug (routing-table op fails ENOBUFS under mbuf
    exhaustion from the flood, and the kernel panics on the unexpected
    failure).  It is present on BOTH kernels and is NOT DF-0417; this fix
    does not address it.

CONCLUSION: the DF-0417 UAF (dangling nd_defrouter pointer stored in a
prefix's pfxrtr list, later field-dereferenced) is CLOSED by the refcount
fix -- the specific nd6_sysctl_prlist / find_pfxlist_reachable_router page
fault no longer reproduces.  fix_status = fixed (for DF-0417).