On Mon, Jan 22, 2018 at 6:42 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > 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 the openvswitch receive path does not perform such trimming, > which will be fixed by the next patch. In preparation, this patch adds > a generic skb_network_trim() function. > > Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
Acked-by: Pravin B Shelar <pshe...@ovn.org> Thanks.
