summaryrefslogtreecommitdiff
path: root/.travis.yml
diff options
context:
space:
mode:
authorEd Swierk <eswierk@skyportsystems.com>2018-02-14 15:18:08 -0800
committerPravin B Shelar <pshelar@ovn.org>2018-02-16 00:41:22 -0800
commitc21adacdc1ba8218545633bf6f6f878e1802fa28 (patch)
tree42807b2ddda89f074e585d9934203909123229a3 /.travis.yml
parent5830593ffc6be0e008d214b7cdd82fe34ad4bedf (diff)
downloadopenvswitch-c21adacdc1ba8218545633bf6f6f878e1802fa28.tar.gz
datapath: Remove padding from packet before L3+ conntrack processing
Upstream commit: commit 9382fe71c0058465e942a633869629929102843d Author: Ed Swierk <eswierk@skyportsystems.com> Date: Wed Jan 31 18:48:02 2018 -0800 openvswitch: Remove padding from packet before L3+ conntrack processing IPv4 and IPv6 packets may arrive with lower-layer padding that is not included in the L3 length. For example, a short IPv4 packet may have up to 6 bytes of padding following the IP payload when received on an Ethernet device with a minimum packet length of 64 bytes. Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(), and help() in nf_conntrack_ftp) assume skb->len reflects the length of the L3 header and payload, rather than referring back to ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by lower-layer padding. In the normal IPv4 receive path, ip_rcv() trims the packet to ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly in the br_netfilter receive path, br_validate_ipv4() and br_validate_ipv6() trim the packet to the L3 length before invoking netfilter hooks. Currently in the OVS conntrack receive path, ovs_ct_execute() pulls the skb to the L3 header but does not trim it to the L3 length before calling nf_conntrack_in(NF_INET_PRE_ROUTING). When nf_conntrack_proto_tcp encounters a packet with lower-layer padding, nf_ip_checksum() fails causing a "nf_ct_tcp: bad TCP checksum" log message. While extra zero bytes don't affect the checksum, the length in the IP pseudoheader does. That length is based on skb->len, and without trimming, it doesn't match the length the sender used when computing the checksum. In ovs_ct_execute(), trim the skb to the L3 length before higher-layer processing. Signed-off-by: Ed Swierk <eswierk@skyportsystems.com> Acked-by: Pravin B Shelar <pshelar@ovn.org> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Ed Swierk <eswierk@skyportsystems.com> Signed-off-by: Greg Rose <gvrose8192@gmail.com> Acked-by: Pravin B Shelar <pshelar@ovn.org>
Diffstat (limited to '.travis.yml')
0 files changed, 0 insertions, 0 deletions