## Summary A malicious guest can abort the QEMU process by sending a crafted TSO frame through an emulated NIC. The TX segmentation code stores a 32-bit header-length sum into the 16-bit `virt_hdr.hdr_len` field. The value wraps, a later subtraction underflows to roughly SIZE_MAX, and `g_malloc()` aborts the process. This is a denial of service. No memory corruption or information leak follows. ## Details - Component: `hw/net/net_tx_pkt.c`, the TX TCP-segmentation path, reached through the emulated NIC TX path such as `hw/net/e1000e_core.c`. - Affected: current master, verified at commit `5611a9268d`. The code has stood unchanged since `02ef5fdc09` (2023). - Reachability: the e1000e NIC (the q35 default) on the standard TSO path, with no special device flag. The same code serves other NICs that use software TSO fragmentation, such as igb and vmxnet3. ## Security boundary Untrusted guest input crashes the host QEMU process. I am filing as confidential per the project's caution guidance. If maintainers judge a self-inflicted crash of the guest's own QEMU process to fall outside the security boundary, please reclassify it as an ordinary bug. ## Root cause `net_tx_pkt_build_vheader()` writes a 32-bit sum into the 16-bit `hdr_len` field of `struct virtio_net_hdr` (the `virt_hdr` member sits at `net_tx_pkt.c:36`): ```c /* net_tx_pkt.c:352 (VIRTIO_NET_HDR_GSO_TCPV4 / TCPV6) */ pkt->virt_hdr.hdr_len = pkt->hdr_len + l4hdr.th_off * sizeof(uint32_t); ``` Two guest-controlled inputs feed that line: - `pkt->hdr_len` is the parsed L2+L3 header length (`net_tx_pkt.c:156`). A guest drives it close to 65535 through an IPv6 extension-header chain, bounded only by the check at `net_tx_pkt.c:250` (`ETH_MAX_IP_DGRAM_LEN == 0xFFFF`). - `l4hdr.th_off` is the 4-bit TCP data offset (max 15), guarded at `net_tx_pkt.c:348` to add between 20 and 60 bytes. When the sum exceeds 65535, the 16-bit store wraps to a small value. The fragmentation path then consumes it: ```c /* net_tx_pkt.c:604 */ l4->iov_len = pkt->virt_hdr.hdr_len - pkt->hdr_len; /* e.g. 2 - 65478 */ /* net_tx_pkt.c:605 */ l4->iov_base = g_malloc(l4->iov_len); /* size near SIZE_MAX */ ``` `l4->iov_len` is a `size_t`, so the subtraction underflows to a value near SIZE_MAX (for example 0xffffffffffff003c), and GLib aborts on the oversized allocation. ## Reproduction Drive the real e1000e TX path against unmodified device source, using BAR0 MMIO, a guest-RAM TX descriptor ring, and a `TDT` doorbell. 1. TX context descriptor: `DEXT | TSE | IP | TCP`. 2. TX data descriptor(s): `DEXT | DTYP_D | TSE | EOP`, with the buffer holding a 14-byte Ethernet header (ethertype 0x86DD), a 40-byte IPv6 base header, a hop-by-hop extension chain summing L3 to about 65464 bytes, a 60-byte TCP header (`th_off = 15`), and a small payload. 3. Write `TDT` to start TX. GLib then aborts on the oversized allocation: ``` GLib: gmem.c: failed to allocate 18446744073709486140 bytes ``` The process receives SIGABRT. The backtrace runs `e1000e_set_tdt`, `e1000e_start_xmit`, `e1000e_process_tx_desc`, `e1000e_tx_pkt_send`, `net_tx_pkt_send_custom`, `net_tx_pkt_do_sw_fragmentation`, and `net_tx_pkt_tcp_fragment_init` at `net_tx_pkt.c:605`. A control frame with L3 just below the wrap window transmits normally, which confirms the window as the cause. The result is deterministic. A qtest fuzz reproducer (trigger seed, control seed, expected output) is available on request. ## Why this is a denial of service only The dangerous allocation never yields a usable out-of-bounds buffer: - The wrap path always sets `l4->iov_len` near SIZE_MAX, because the term added before the wrap reaches at most 60 while the wrap subtracts 65536. `g_malloc()` aborts before any copy runs. - The normal path fills exactly `l4->iov_len` bytes, and on fragment exhaustion it frees the buffer and returns false (`net_tx_pkt.c:615-617`) before any use. Every write stays in bounds, and no uninitialized memory reaches the guest. ## Proposed fix Reject the malformed packet before the subtraction. A minimal guard at the use site: ```diff @@ net_tx_pkt_tcp_fragment_init if (!pkt->payload_frags) { return false; } + if (pkt->virt_hdr.hdr_len < pkt->hdr_len) { + return false; + } + l4->iov_len = pkt->virt_hdr.hdr_len - pkt->hdr_len; l4->iov_base = g_malloc(l4->iov_len); ``` A root-cause alternative rejects the packet in `net_tx_pkt_build_vheader()` when the header length overflows the 16-bit field, covering both the TCP store at `net_tx_pkt.c:352` and the UDP store at `net_tx_pkt.c:340`: ```c if (pkt->hdr_len + l4hdr.th_off * sizeof(uint32_t) > UINT16_MAX) { return false; } ``` I can submit either as a patch to qemu-devel. ## Prior art and dedup Based on the public issue tracker, this has not been reported yet. The closest neighbors were: - #1544 "Abort in net_tx_pkt_do_sw_fragmentation" (2023) aborts at `net_tx_pkt.c:739` from a misaligned IP header. Commits `4cf3a638` and `2a5f744e` fixed that separate defect. This report concerns the `g_malloc` abort at `net_tx_pkt.c:605`. - #2273 "Abort in net_tx_pkt_update_sctp_checksum" (2024) sits in a different function and is fixed. - #3472 "e1000e hang in main_loop_wait" (2025) is a qtest timer spin in QEMU core; its reporter instrumented `net_tx_pkt` and saw no hits. I can't see confidential issues, so please dedup against your private records. ## Origin IronCurtain LLM-assisted source analysis found this issue, including confirmation with a runtime reproducer. Yes, this is AI assisted. Hopefully not just slop.