Bug 236853 - panic: page fault on rtsock.c
Summary: panic: page fault on rtsock.c
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: i386 Any
: --- Affects Many People
Assignee: freebsd-net mailing list
URL:
Keywords: panic
Depends on:
Blocks:
 
Reported: 2019-03-28 15:28 UTC by lenzi.sergio
Modified: 2019-03-30 13:43 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lenzi.sergio 2019-03-28 15:28:43 UTC
The system panics on /usr/src/sys/net/rtsock.c:839 and all references to ifp->if_addr->ifa_addr   the pointer ifp->if_addr is invalid.  some race condition occurs that releases the ifp->if_addr and when the code tries to read the next pointer a page fault occurs.... sometimes it happens in /usr/src/sys/net/rtsock.c:1581 too

how to reproduce:
setup (1) a freebsd 12 or 13 as a ppp-in server (man ppp) using the setup in the example at http://www.k1.com.br/crash/ppp, than go to another freebsd and using the ppptun.conf, connect to the (1)  using the command ppp -ddial ppptun after several connects and disconnects, the (1)  panics...  sometimes the simple route get "any ppp address"  is enough to panic the system.

The resulting debug files of the panic is in the http://www.k1.com.br/crash
Comment 1 Eugene Grosbein freebsd_committer 2019-03-30 11:48:05 UTC
Please specify exact revisions of FreeBSD you are using as very similar problem was fixed not long ago.

CC'ing ae@ just in case it's new.
Comment 2 Andrey V. Elsukov freebsd_committer 2019-03-30 12:51:35 UTC
(In reply to Eugene Grosbein from comment #1)
> Please specify exact revisions of FreeBSD you are using as very similar
> problem was fixed not long ago.
> 
> CC'ing ae@ just in case it's new.

It is CURRENT, you can see revision for each dump in core.txt.
I don't think this problem was fixed. I suspect the problem occurs when tun(4) interfaces are going down. There are two sorts of panic, one is in nd6_dad_timer(), second is in route_output(). It seems in both cases ifnet pointer is already freed.
Comment 3 Andrey V. Elsukov freebsd_committer 2019-03-30 13:43:11 UTC
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0xdeadc0e6
fault code		= supervisor read data, page not present
instruction pointer	= 0x20:0x10554cb
stack pointer	        = 0x28:0x13ef3ba0
frame pointer	        = 0x28:0x13ef3c04
code segment		= base rx0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 12 (swi4: clock (0))
trap number		= 12
panic: page fault
cpuid = 0
time = 1553520118
KDB: stack backtrace:
db_trace_self_wrapper(ccc1c1,1,ac27dc0,13ef39bc,b4dd91,...) at db_trace_self_wrapper+0x2a/frame 0x13ef3990
kdb_backtrace(e,0,0,13ef3b60,13ef3b60,...) at kdb_backtrace+0x2e/frame 0x13ef39f0
vpanic(1243776,13ef3a34,13ef3a34,13ef3a68,11ef956,...) at vpanic+0x121/frame 0x13ef3a14
panic(1243776,12b225a,2695000,0,deadc0e6,...) at panic+0x14/frame 0x13ef3a28
trap_fatal(15dc000,13ef3b60,13ef3a9c,e556d2,265dc000,...) at trap_fatal+0x356/frame 0x13ef3a68
trap_pfault(deadc0e6) at trap_pfault+0x35/frame 0x13ef3a9c
trap(13ef3b60,8,28,28,ad9b400,...) at trap+0x3c0/frame 0x13ef3b54
calltrap() at 0xffc0316d/frame 0x13ef3b54
--- trap 0xc, eip = 0x10554cb, esp = 0x13ef3ba0, ebp = 0x13ef3c04 ---
nd6_dad_timer(1d1fe980) at nd6_dad_timer+0x5b/frame 0x13ef3c04
softclock_call_cc(0) at softclock_call_cc+0x122/frame 0x13ef3c68
softclock(1868640) at softclock+0x6f/frame 0x13ef3c84
ithread_loop(adfbf20,13ef3ce8) at ithread_loop+0x156/frame 0x13ef3cb4
fork_exit(dfc5c0,adfbf20,13ef3ce8,0,0,...) at fork_exit+0x6c/frame 0x13ef3cd4
fork_trampoline() at 0xffc033ca/frame 0x13ef3cd4
--- trap 0, eip = 0, esp = 0x13ef3d20, ebp = 0 ---
(null)() at 0

This panic seems happens due to bad pointer dereference in:
if (ND_IFINFO(ifp)->flags & ND6_IFF_IFDISABLED)

The difference between 0xdeadc0e6 and 0xdeadc0de is 8. So, for i386 it seems it corresponds to offsetof(struct in6_ifextra, nd_ifinfo). And

#define ND_IFINFO(ifp) \
 nd6_dad_stop(struct ifaddr *ifa)(((struct in6_ifextra *)(ifp)->if_afdata[AF_INET6])->nd_ifinfo)

Can you show the content of *dp and *ifp for 8 frame for vmcore.4?
I.e.
(kgdb)
f 8
p *dp
p *ifp