Public bug reported: My vmxnet3 network driver (in a closed source custom OS) is unable to send network packets that are structured as follows: Ethernet- Header(IPv6-Header(ESP(encrypted data))). I can verify that the packet is sent in the VM but is dropped in qemu. I first encountered this problem on qemu 2.10.1 but master is affected as well. After some debug printing in qemu I could identify the following call chain as being problematic:
eth_is_ip6_extension_header_type eth_parse_ipv6_hdr net_tx_pkt_parse_headers net_tx_pkt_parse vmxnet3_process_tx_queue The problem seems to be the definition of the ESP header (https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload) that does not follow the standard IPv6 extension header format starting with next type and length. Thus the parsed ext_hdr in eth_parse_ipv6_hdr does not contain valid data, in particular the length will contain bogus data and lead to a info->full_hdr_len that is larger than the packet itself and the loop would then try to read beyond the end of the packet. Using the e1000 driver I can send these packets. My guess is that the net_tx_pkt_parse function is not called in that case. My guess for a fix would be to remove "case IP6_ESP:" from eth_is_ip6_extension_header_type and not regard the ESP header as a IPv6 extension header. In a quick test this seems to fix the problem. But that should be verified by someone who is familiar with the code. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1758091 Title: vmxnet3 unable to send IPv6 ESP packets Status in QEMU: New Bug description: My vmxnet3 network driver (in a closed source custom OS) is unable to send network packets that are structured as follows: Ethernet- Header(IPv6-Header(ESP(encrypted data))). I can verify that the packet is sent in the VM but is dropped in qemu. I first encountered this problem on qemu 2.10.1 but master is affected as well. After some debug printing in qemu I could identify the following call chain as being problematic: eth_is_ip6_extension_header_type eth_parse_ipv6_hdr net_tx_pkt_parse_headers net_tx_pkt_parse vmxnet3_process_tx_queue The problem seems to be the definition of the ESP header (https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload) that does not follow the standard IPv6 extension header format starting with next type and length. Thus the parsed ext_hdr in eth_parse_ipv6_hdr does not contain valid data, in particular the length will contain bogus data and lead to a info->full_hdr_len that is larger than the packet itself and the loop would then try to read beyond the end of the packet. Using the e1000 driver I can send these packets. My guess is that the net_tx_pkt_parse function is not called in that case. My guess for a fix would be to remove "case IP6_ESP:" from eth_is_ip6_extension_header_type and not regard the ESP header as a IPv6 extension header. In a quick test this seems to fix the problem. But that should be verified by someone who is familiar with the code. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1758091/+subscriptions