https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285129
Bug ID: 285129
Summary: netinet(6)/route: uninitialized access of ifp->if_data
in ip6_tryforward() with PPPoE/ng interface
Product: Base System
Version: 14.2-STABLE
Hardware: Any
URL: https://github.com/opnsense/src/issues/207
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Hi,
Looking at a panic in ip6_tryforward() related to PPPoE, for details see the
downstream bug report. Backtrace is:
--- trap 0xc, rip = 0xffffffff80ddb5d7, rsp = 0xfffffe0038bd6840, rbp =
0xfffffe0038bd6970 ---
ip6_forward() at ip6_forward+0x2a7/frame 0xfffffe0038bd6970
ip6_input() at ip6_input+0x11f/frame 0xfffffe0038bd6a50
netisr_dispatch_src() at netisr_dispatch_src+0x9e/frame 0xfffffe0038bd6aa0
ether_demux() at ether_demux+0x149/frame 0xfffffe0038bd6ad0
ether_nh_input() at ether_nh_input+0x36a/frame 0xfffffe0038bd6b30
netisr_dispatch_src() at netisr_dispatch_src+0x9e/frame 0xfffffe0038bd6b80
ether_input() at ether_input+0x56/frame 0xfffffe0038bd6bd0
ether_demux() at ether_demux+0x97/frame 0xfffffe0038bd6c00
ether_nh_input() at ether_nh_input+0x36a/frame 0xfffffe0038bd6c60
netisr_dispatch_src() at netisr_dispatch_src+0x9e/frame 0xfffffe0038bd6cb0
ether_input() at ether_input+0x56/frame 0xfffffe0038bd6d00
iflib_rxeof() at iflib_rxeof+0xc0e/frame 0xfffffe0038bd6e00
_task_fn_rx() at _task_fn_rx+0x72/frame 0xfffffe0038bd6e40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x14e/frame 0xfffffe0038bd6ec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame
0xfffffe0038bd6ef0
fork_exit() at fork_exit+0x7f/frame 0xfffffe0038bd6f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0038bd6f30
--- trap 0x9d9d3e64, rip = 0xb414471ee4b2474b, rsp = 0x3113c21961b5c24c, rbp =
0x5647a54d06e1a518 ---
Got a debug core and here is what it says:
(kgdb) frame 17
#17 0xffffffff80e0f6fc in ip6_tryforward (m=0xfffff80053520d00) at
/usr/src/sys/netinet6/ip6_fastfwd.c:194
194 mtu = IN6_LINKMTU(nifp);
(kgdb) p nifp->if_xname
$1 = "pppoe0\000\000\000\000\000\000\000\000\000"
(kgdb) p nifp->if_afdata
$2 = {0x0 <repeats 44 times>}
(kgdb) p nifp->if_afdata_initialized
$3 = 0
Yes, the code is slightly modified, but it's 100% not self-inflicted. You can
also find a similar panic here:
https://redmine.pfsense.org/issues/15640
To unpack, IN6_LINKMTU() uses if_getifdata() which reaches for if_afdata but
that is not yet initialized (or maybe it's about to be teared down).
I'll put up a review for discussion in a bit. Fixing this one instance seems
trivial but the issue reaching for if_afdata unconditionally seems to be all
over the stack.
Cheers,
Franco
--
You are receiving this mail because:
You are the assignee for the bug.
