diff options
Diffstat (limited to 'results/classifier/deepseek-2/output/network/1758091')
| -rw-r--r-- | results/classifier/deepseek-2/output/network/1758091 | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2/output/network/1758091 b/results/classifier/deepseek-2/output/network/1758091 new file mode 100644 index 000000000..a149c2667 --- /dev/null +++ b/results/classifier/deepseek-2/output/network/1758091 @@ -0,0 +1,16 @@ + +vmxnet3 unable to send IPv6 ESP packets + +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. \ No newline at end of file |