From: Stefano Brivio <[email protected]>
Date: Thu,  3 May 2018 18:13:25 +0200

> If an OVS_ATTR_NESTED attribute type is found while walking
> through netlink attributes, we call nlattr_set() recursively
> passing the length table for the following nested attributes, if
> different from the current one.
> 
> However, once we're done with those sub-nested attributes, we
> should continue walking through attributes using the current
> table, instead of using the one related to the sub-nested
> attributes.
> 
> For example, given this sequence:
> 
> 1  OVS_KEY_ATTR_PRIORITY
> 2  OVS_KEY_ATTR_TUNNEL
> 3     OVS_TUNNEL_KEY_ATTR_ID
> 4     OVS_TUNNEL_KEY_ATTR_IPV4_SRC
> 5     OVS_TUNNEL_KEY_ATTR_IPV4_DST
> 6     OVS_TUNNEL_KEY_ATTR_TTL
> 7     OVS_TUNNEL_KEY_ATTR_TP_SRC
> 8     OVS_TUNNEL_KEY_ATTR_TP_DST
> 9  OVS_KEY_ATTR_IN_PORT
> 10 OVS_KEY_ATTR_SKB_MARK
> 11 OVS_KEY_ATTR_MPLS
> 
> we switch to the 'ovs_tunnel_key_lens' table on attribute #3,
> and we don't switch back to 'ovs_key_lens' while setting
> attributes #9 to #11 in the sequence. As OVS_KEY_ATTR_MPLS
> evaluates to 21, and the array size of 'ovs_tunnel_key_lens' is
> 15, we also get this kind of KASan splat while accessing the
> wrong table:
 ...
> Reported-by: Hangbin Liu <[email protected]>
> Fixes: 982b52700482 ("openvswitch: Fix mask generation for nested 
> attributes.")
> Signed-off-by: Stefano Brivio <[email protected]>
> Reviewed-by: Sabrina Dubroca <[email protected]>

Looks good, applied and queued up for -stable.

Thanks.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to