[ovs-dev] [PATCH/RFC] flow: Ignore miss-sized IPv6 neighbour discovery options

Simon Horman simon.horman at netronome.com
Fri Aug 7 02:43:57 UTC 2015


On Thu, Aug 06, 2015 at 04:00:36PM -0700, Jesse Gross wrote:
> On Wed, Aug 5, 2015 at 10:20 PM, Simon Horman
> <simon.horman at netronome.com> wrote:
> > There appears to be a miss-match between the handling of miss-sized
> > neighbour discovery options in implementation of
> > parse_icmpv6() in user-space and in the kernel datapath.
> >
> > This patch addresses that by modifying the user-space handling to
> > match that of the kernel datapath; processing is terminated without
> > rather than with an error.
> >
> > The result of this is that the ICMPv6 type and code are present in
> > the flow and thus may be matched on, which seems logical.
> >
> > I can across this while investigating why neighbour solicitation packets
> > with an option whose header has type and length both set to zero did
> > not hit a rule that matches on its type.
> >
> > Signed-off-by: Simon Horman <simon.horman at netronome.com>
> 
> I agree this is a bug and I think the unwanted side effects are likely
> pretty minimal.
> 
> However, doesn't this logic to all of the invalid paths in this
> function? The kernel always populates the ICMPv6 type and code
> regardless of neighbor discovery processing. The only thing the
> invalid target does in that case is clear any half parsed ND
> information.

Are you referring to the following in lib/flow.c:parse_icmpv6() ?


        *nd_target = data_try_pull(datap, sizep, sizeof **nd_target);
        if (OVS_UNLIKELY(!*nd_target)) {
            return false;
        }

	...


            if (OVS_UNLIKELY(!data_try_pull(datap, sizep, opt_len))) {
                goto invalid;
            }

If so, yes, now I look at the code again it looks like they are
also inconsistent with the kernel implementation and could be
changed to return true.



More information about the dev mailing list