On 2015-03-11 13:50:50 (+0100), Kristof Provost wrote:
> On 2015-03-11 12:50:23 (+0300), Andrey V. Elsukov wrote:
> > It looks like there are some code paths that do a copy of original mbuf.
> > Are you sure this doesn't introduce mbuf leak?
> >
> I'll check again in the morning when I'm less dr
On 2015-03-11 12:50:23 (+0300), Andrey V. Elsukov wrote:
> It looks like there are some code paths that do a copy of original mbuf.
> Are you sure this doesn't introduce mbuf leak?
>
I'll check again in the morning when I'm less drunk and jet lagged, but
I'm pretty confident this is correct.
Ther
On 11.03.2015 11:39, Kristof Provost wrote:
> The pf code in pf_route6() neglected to set the mbuf pointer to NULL
> after the call to ip6_output(). As a result we end up trying to continue
> processing on an mbuf which has already been freed.
> ---
> sys/netpfil/pf/pf.c | 1 +
> 1 file changed, 1
Set up a pf ruleset with at least the following rule
> pass out fastroute inet6 proto icmp6 all icmp6-type echoreq
Send out an icmp6 echo request (i.e. ping6 2001:db8::1). This causes a
panic in ip6_output() when comparing the old and new destination
addresses (IN6_ARE_ADDR_EQUAL()) just after the
