> 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?
>
> thanks and
> regards
> sashan
>
> --------8<---------------8<---------------8<------------------8<--------
> diff --git a/sys/net/if_veb.c b/sys/net/if_veb.c
> index 67185fde228..30a002f95a2 100644
> --- a/sys/net/if_veb.c
> +++ b/sys/net/if_veb.c
> @@ -944,7 +944,7 @@ veb_broadcast(struct veb_softc *sc, struct veb_port *rp,
> struct mbuf *m0,
> * let pf look at it, but use the veb interface as a proxy.
> */
> if (ISSET(ifp->if_flags, IFF_LINK1) &&
> - (m = veb_pf(ifp, PF_OUT, m0)) == NULL)
> + (m0 = veb_pf(ifp, PF_OUT, m0)) == NULL)
> return;
> #endif
>
>
