OSDN Git Service

net/eth: Don't consider ESP to be an IPv6 option header
authorThomas Jansen <mithi@mithi.net>
Sat, 12 Feb 2022 18:56:41 +0000 (19:56 +0100)
committerJason Wang <jasowang@redhat.com>
Mon, 14 Feb 2022 03:50:44 +0000 (11:50 +0800)
commit9d6267b240c114d1a3cd314a08fd6e1339d34b83
treebcdcc52d3e744b42418cefe1eccc0d91eaedf181
parent870374214e4cc122f086f55732f1b17ec320132e
net/eth: Don't consider ESP to be an IPv6 option header

The IPv6 option headers all have in common that they start with some
common fields, in particular the type of the next header followed by the
extention header length. This is used to traverse the list of the
options. The ESP header does not follow that format, which can break the
IPv6 option header traversal code in eth_parse_ipv6_hdr().

The effect of that is that network interfaces such as vmxnet3 that use
the following call chain
  eth_is_ip6_extension_header_type
  eth_parse_ipv6_hdr
  net_tx_pkt_parse_headers
  net_tx_pkt_parse
  vmxnet3_process_tx_queue
to send packets from the VM out to the host will drop packets of the
following structure:
  Ethernet-Header(IPv6-Header(ESP(encrypted data)))

Note that not all types of network interfaces use the net_tx_pkt_parse
function though, leading to inconsistent behavior regarding sending
those packets. The e1000 network interface for example does not suffer
from this limitation.

By not considering ESP to be an IPv6 header we can allow sending those
packets out to the host on all types of network interfaces.

Fixes: 75020a702151 ("Common definitions for VMWARE devices")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/149
Buglink: https://bugs.launchpad.net/qemu/+bug/1758091
Signed-off-by: Thomas Jansen <mithi@mithi.net>
Signed-off-by: Jason Wang <jasowang@redhat.com>
net/eth.c