Public bug reported:
When a guest packet is an IPv4 TCP ACK with no payload and is padded to the
60-byte Ethernet minimum, QEMU e1000e transmit processing rewrites the IPv4
total length to include Ethernet padding. The receiving TLS endpoint treats the
padding as payload and may reset the connection.
Environment:
- Ubuntu compute host running OpenStack with Kolla Ansible
- Nested ESXi server deployed on OpenStack
- e1000e NIC driver in use for the ESXi guest
Management network contains:
- ESXi hosts
- Windows jumpbox
fabric@atc-clb-dev-os-gpc-01:~$ lsb_release -rd
No LSB modules are available.
Description: Ubuntu 24.04.4 LTS
Release: 24.04
fabric@atc-clb-dev-os-gpc-01:~$ sudo podman exec -ti nova_libvirt
qemu-system-x86_64 --version
QEMU emulator version 8.2.2 (Debian 1:8.2.2+ds-0ubuntu1.16)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers
fabric@atc-clb-dev-os-gpc-01:~$
Steps to reproduce:
- Run nested ESXi on Ubuntu/OpenStack with a Kolla container image.
- Open a TLS session from the Windows jumpbox to the ESXi management UI.
- Observe ESXi sending a pure TCP ACK response to the TLS ClientHello.
- Capture the packet on the host network.
Verify:
- IPv4 header total length should be 40 when esxi transmits this packet
- packet is padded to Ethernet minimum frame size of 60 bytes (14 bytes Eth
header + 20 bytes ip header + 20 bytes tcp header + 6 bytes pad)
- QEMU e1000e transmit path rewrites IP total length to 46
Actual behavior:
- ESXi sends an IPv4 TCP ACK with original ip_len = 40
- Ethernet layer adds 6 bytes padding to reach 60 bytes
- QEMU e1000e processing overwrites IPv4 total length to 46
- The receiver treats the padded bytes as payload
- TLS connection is reset / fails
Expected behavior:
- The IPv4 total length remains 40
- Ethernet padding is not counted as IP payload
- TCP pseudo-header checksum remains correct
- TLS session continues normally
Root cause:
The bug is in QEMU packet rebuild/transmission logic:
net_tx_pkt.c, net_tx_pkt_rebuild_payload()
For IPv4, iov_size() counts Ethernet padding in raw_payload_len
net_tx_pkt_update_ip_hdr_checksum() then computes ip_len from the inflated
payload length
That causes the IPv4 header and TCP checksum to be corrupted for short padded
frames
This is exposed by the e1000e transmit path in e1000e_core.c, which uses
net_tx_pkt_parse() and packet rebuild logic.
Impact
Breaks TLS connections on ACK-only IPv4 packets
Affects nested ESXi management traffic in Kolla/OpenStack on Ubuntu
Likely affects any setup where e1000e handles padded short IPv4 packets
Notes:
This is visible in Ubuntu’s packaged qemu, but the underlying bug is upstream
in QEMU source code.
If possible, please forward to upstream QEMU maintainers or reference
net_tx_pkt.c and e1000e_core.c in the bug.
A path for this issue is attached with this report.
** Affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "path for the issue. please apply this patch if possible."
https://bugs.launchpad.net/bugs/2158017/+attachment/5978665/+files/0001-e1000e-fix-ip-total-length-clamping-for-padded-frames.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2158017
Title:
qemu e1000e transmit path overwrites IPv4 total length on short padded
TCP ACKs, causing TLS reset
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2158017/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
