[Bug 285129] netinet(6)/route: uninitialized access of ifp->if_data in ip6_tryforward() with PPPoE/ng interface

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: bugs@FreeBSD.org
          Reporter: franco@opnsense.org

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.