Hello David,
On Sun, May 29, 2022 at 12:59:25PM +1000, David Gwynne wrote:
>
>
> > On 24 May 2022, at 17:01, Alexandr Nedvedicky
> > <alexandr.nedvedi...@oracle.com> wrote:
> >
> > Hello Hrvoje,
> >
> > On Mon, May 23, 2022 at 06:34:07PM +0200, Hrvoje Popovski wrote:
> >> On 23.5.2022. 10:41, Hrvoje Popovski wrote:
> >>> On 23.5.2022. 8:34, Alexandr Nedvedicky wrote:
> >>>> looks like kind of memory corruption. my bet is use-after-free.
> >>>> will try to get to it later today.
> >>>>
> >>>> does it mean there is no such panic, when we handle IPv4 traffic only?
> >>>
> >>> Hi,
> >>>
> >>> yes, it seems that i can't trigger panic with ip4 only traffic, at least
> >>> the same way i can with ip6 traffic
> >>>
> >>
> >> All day I'm trying to trigger panic with ip4 and I just can't ....
> >
> > interesting. I went through mbuf handling in if_veb.c
> > I just could find a single nit, which is most likely unrelated,
> > however I think it's still worth to give it a try a diff below.
> >
> > basically all calls to veb_pf() read as follows:
> > m = veb_pf(ifp, ..., m);
> > except the one in veb_broadcast(), which readsa as:
> > m = veb_pf(ifp, ..., m0);
> > I think it is a bug, veb_pf() caller should continue to run
> > with packet returned by veb_pf().
>
> yes. ok by me. can you fix the same thing in the ipsec handling too?
>
yes will do. I'm still testing those changes on Hrvoje's playground.
there are still few more nits around IPv6 I'd to understand better.
It well might be the tools (?pkgtgen?) don't generate a valid IPv6
packets or pf(4) is just too paranoid/picky.
thanks and
regards
sashan
