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

Reply via email to