Date: Tue, 30 Sep 2025 10:35:30 -0700 From: Gleb Smirnoff <glebius@freebsd.org> To: Mateusz Guzik <mjguzik@gmail.com>, Zhenlei Huang <zlei@freebsd.org> Cc: src-committers@freebsd.org, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@FreeBSD.org" <dev-commits-src-main@freebsd.org> Subject: Re: svn commit: r256519 - in head/sys: net netatalk netinet netinet6 netipx Message-ID: <aNwU4pW_PQs1yYRo@cell.glebi.us> In-Reply-To: <CAGudoHGN=6-dFQ791_=kLBnYfyz9zm75-vJKh=e9gibaXun5NQ@mail.gmail.com> References: <201310151031.r9FAVgRP008282@svn.freebsd.org> <CAGudoHGN=6-dFQ791_=kLBnYfyz9zm75-vJKh=e9gibaXun5NQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mateusz, On Mon, Sep 29, 2025 at 04:29:10PM +0200, Mateusz Guzik wrote: M> We have crashes stemming from this: M> M> panic: ifa_alloc: invalid size 16 M> M> panic() at panic+0x43/frame 0xfffffe009e777760 M> ifa_alloc() at ifa_alloc+0xd6/frame 0xfffffe009e777780 M> in6_ifadd() at in6_ifadd+0xd8/frame 0xfffffe009e7778a0 M> nd6_ra_input() at nd6_ra_input+0x1023/frame 0xfffffe009e777a80 M> icmp6_input() at icmp6_input+0x5b6/frame 0xfffffe009e777c00 M> ip6_input() at ip6_input+0xc94/frame 0xfffffe009e777ce0 M> sppp_input() at sppp_input+0x502/frame 0xfffffe009e777d70 M> pppoe_data_input() at pppoe_data_input+0x1e7/frame 0xfffffe009e777de0 M> swi_net() at swi_net+0x19b/frame 0xfffffe009e777e60 M> ithread_loop() at ithread_loop+0x266/frame 0xfffffe009e777ef0 M> fork_exit() at fork_exit+0x82/frame 0xfffffe009e777f30 M> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe009e777f30 M> M> in6_ifadd has: M> struct in6_addr taddr; M> ifa = ifa_alloc(sizeof(taddr), M_WAITOK); M> M> should the assert be simply removed? As Zhenlei already noticed sizeof(taddr) is incorrect there. But why are you the first to catch this panic? Even before my change in 2013 this code was incorrect, it would allocate too little memory for struct ifaddr and would later lead to trashing adjacent memory. Even the function itself will immeditely read memory in front of the allocation. I guess this branch was never ever executed since export from KAME. There are two possibilities here: 1) in6ifa_ifpforlinklocal() returns NULL. Your external pppoe/sppp interface doesn't have link local address assigned, but is already receiving incoming traffic. This is what needs to be fixed. I'm not netinet6 expert enough to say what mechanism prevents other ifnet types to get into this state, but definitely there something special about yours. 2) We are hitting (prefixlen != plen0) branch. Do you see the printf "%s: wrong prefixlen for %s (prefix=%d ifid=%d)\n" before the panic? Most likely this is 1). Your interace type needs to be fixed and this function reduced of code that shall never happen. -- Gleb Smirnoff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aNwU4pW_PQs1yYRo>