[Bug 201932] panic: pf_frag_tree_RB_FIND - dereference to 0xdeadc0dedeadc0de

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201932

            Bug ID: 201932
           Summary: panic: pf_frag_tree_RB_FIND - dereference to
                    0xdeadc0dedeadc0de
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: peter at FreeBSD.org
                CC: kp at freebsd.org

My 11.0-CURRENT @ 285923 is panicing on boot due to a 0xdeadc0de dereference in
pf_frag_tree_RB_FIND().

I had a 'scrub in all' and the panic is avoided by commenting it out.  IPv6 is
compiled in, but not configured aside from ::1 and a fe80:: link local address
that isn't otherwise used.

#8  0xffffffff807d71c3 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:235
#9  0xffffffff807228d4 in pf_frag_tree_RB_FIND (head=<value optimized out>,
elm=0xfffffe066501e588)
    at /usr/src/sys/netpfil/pf/pf_norm.c:217
#10 0xffffffff80724d55 in pf_find_fragment (key=0xfffffe066501e588,
tree=0xffffffff80d52a40)
    at /usr/src/sys/netpfil/pf/pf_norm.c:331
#11 0xffffffff80723a86 in pf_normalize_ip (m0=0xfffffe066501e7d8, dir=1,
kif=0xfffff8000a106800, 
    reason=0xfffffe066501e72e, pd=0xfffffe066501e698) at
/usr/src/sys/netpfil/pf/pf_norm.c:1268
#12 0xffffffff807099f4 in pf_test (dir=1, ifp=<value optimized out>,
m0=0xfffffe066501e7d8, inp=0x0)
    at /usr/src/sys/netpfil/pf/pf.c:5750
#13 0xffffffff8071ac9d in pf_check_in (arg=<value optimized out>,
m=0xfffffe066501e7d8, ifp=0xfffffe066501e588, 
    dir=<value optimized out>, inp=0x149) at
/usr/src/sys/netpfil/pf/pf_ioctl.c:3555
#14 0xffffffff8068ac83 in pfil_run_hooks (ph=0xffffffff80e4f3e8,
mp=0xfffffe066501e860, ifp=0xfffff8000850c800, 
    dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:83
#15 0xffffffff806b4439 in ip_input (m=0xffffffff063091d8) at
/usr/src/sys/netinet/ip_input.c:523
#16 0xffffffff80689b06 in netisr_dispatch_src (proto=<value optimized out>,
source=<value optimized out>, 
    m=0xfffff80016a9bb00) at /usr/src/sys/net/netisr.c:972

It appears to be inside pf_frag_compare() as inlined into the RB lookup.

The actual crash is a dereference of %rbx register, which had the value
0xdeadc0dedeadc0de.  INVARIANTS was enabled so that means a use-after-free.

Notable config fragments:
options         KDB                     #Enable the kernel debugger
options         DDB                     #Enable the kernel debugger
options         KDB_TRACE
options         INVARIANTS              #Enable calls of extra sanity checking
options         INVARIANT_SUPPORT       #Extra sanity checks of internal
structures, required by INVARIANTS
options         ALT_BREAK_TO_DEBUGGER
device          pf
device          pflog
options         ALTQ
options         ALTQ_CBQ        # Class Bases Queueing
options         ALTQ_RED        # Random Early Drop
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler
options         ALTQ_CDNR       # Traffic conditioner
options         ALTQ_PRIQ       # Priority Queueing
options         NETGRAPH                # netgraph(4) system
options         NETGRAPH_IFACE
options         NETGRAPH_KSOCKET
options         NETGRAPH_SOCKET

The netgraph/altq stuff is a leftover of experiments years ago. It isn't in
use, although it is present.

General structure of pf.conf:
ext_if="bge1"
ext_ip4="XX.XX.XX.XX"

set loginterface $ext_if
set block-policy return
set skip on lo

# commented out to avoid panic
#scrub in all

nat on $ext_if from 127.0.1.0/24 to any -> $ext_ip4

block return in log on $ext_if all
pass in  on $ext_if inet proto tcp from any to $ext_ip4 port ssh
pass in  on $ext_if inet proto tcp from any to $ext_ip4 port imap
pass in  on $ext_if inet proto tcp from any to $ext_ip4 port imaps
pass in  on $ext_if inet proto icmp all icmp-type echoreq
pass out on $ext_if inet all

There are a number of jails on lo1 with their own 127.0.1.x address.

It consistently died with the same crash, 100% repeatable.  dmesg of the vmcore
shows it died during jail startup.

The host's unbound had started.  It is configured for dnssec validation so it
likely that large udp packets were in play.

-- 
You are receiving this mail because:
You are the assignee for the bug.