On Tue, Dec 22, 2015 at 7:13 PM, Daniele Di Proietto <diproiet...@vmware.com> wrote: > > > On 17/12/2015 16:28, "Jesse Gross" <je...@kernel.org> wrote: > >>When handling an upcall with the userspace datapath, it's currently >>possible for a flow from a packet with no tunnel options to come back >>with matches on the options. If that happens, dpif-netdev will >>attempt to translate the wildcards provided by ofproto into the format >>used by dpif. The translation requires use of the original wildcards >>from the flow, which since they didn't exist, is uninitalized memory. >> >>Matching on fields which don't actually exist is itself a bug. However, >>this can occur when we attempt to set a tunnel option on the packet - >>ofproto generates a match on the field in the original packet. This is >>being fixed separately. >> >>In other situations where we have a match on an unexpected field, we >>simply ignore it. This happens with tunnel options with the kernel >>datapath, non-tunnel fields that don't exist in the packet, and even >>with Geneve where we do have some options but not the particular one >>that was matched on. This brings the same behavior for this case and >>avoids the possibility of accessing uninitialized memory. >> >>Reported-by: Daniele Di Proietto <diproiet...@vmware.com> >>Signed-off-by: Jesse Gross <je...@kernel.org> > > Thanks for fixing this! > > Acked-by: Daniele Di Proietto <diproiet...@vmware.com>
Thanks, I applied this to master and branch-2.5. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev