When a packet is received on a tunnel the pad member is currently
left uninitialized. This didn't previously cause problems because
userspace didn't interprete the IPV4_TUNNEL attribute and blindly
copied back the uninitialized data. However, now that userspace
knows how to serialize this attribute it was zeroing it out, which
prevented flows that had been previously installed from being
deleted. In addition to zeroing out the padding on packet reception,
it also does the same thing on flow setup since we should be ignoring
the value.
Reported-by: Anand Krishnamurthy <krishnamurt4@wisc.edu>
Reported-by: Saul St. John <sstjohn@cs.wisc.edu>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
return -EINVAL;
memcpy(&swkey->tun_key, tun_key, sizeof(swkey->tun_key));
+ memset(swkey->tun_key.pad, 0, sizeof(swkey->tun_key.pad));
attrs &= ~(1ULL << OVS_KEY_ATTR_TUN_ID);
attrs &= ~(1ULL << OVS_KEY_ATTR_IPV4_TUNNEL);
return -EINVAL;
memcpy(&swkey->tun_key, tun_key, sizeof(swkey->tun_key));
+ memset(swkey->tun_key.pad, 0, sizeof(swkey->tun_key.pad));
attrs &= ~(1ULL << OVS_KEY_ATTR_IPV4_TUNNEL);
}
tun_key->ipv4_tos = iph->tos;
tun_key->ipv4_ttl = iph->ttl;
tun_key->tun_flags = tun_flags;
+ memset(tun_key->pad, 0, sizeof(tun_key->pad));
}
static inline void tnl_get_param(const struct tnl_mutable_config *mutable,