From: Ed Swierk <eswi...@skyportsystems.com> Date: Wed, 31 Jan 2018 18:48:02 -0800
> 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 <eswi...@skyportsystems.com> Applied, thank you Ed.
