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.hor...@netronome.com>
---
* Some consideration should be given to examining unwanted side effects
of this change. I feel it is probably safe as the kernel has been doing
this. But nonetheless it is a behavioural change for malformed packets.
---
lib/flow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/flow.c b/lib/flow.c
index af51aacf7831..5537f959692a 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -378,7 +378,7 @@ parse_icmpv6(const void **datap, size_t *sizep, const
struct icmp6_hdr *icmp,
int opt_len = nd_opt->nd_opt_len * 8;
if (!opt_len || opt_len > *sizep) {
- goto invalid;
+ return true;
}
/* Store the link layer address if the appropriate option is
--
2.1.4
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
