A flaw was found in libslirp. When handling ICMP echo requests, the reply length is not updated to match the actual data received from the host. Under specific conditions where the normal ICMP socket is unavailable, this length mismatch causes the host's real IP address to be leaked to the guest in the echo reply, breaking the NAT isolation that user-mode networking is expected to provide.
A flaw was found in libslirp's ICMP echo request handling. In the function icmpreceive() in src/ipicmp.c, after receiving an ICMP reply via recv(), the mbuf length (mlen) and IP header length (iplen) are not updated to reflect the actual number of bytes received. They retain the original echo request size.
When the SOCKDGRAM ICMP socket is unavailable (pinggrouprange restricted) and slirp falls back to a SOCKRAW socket, recv() can deliver ICMP error messages (such as Host Unreachable) instead of echo replies. These messages are shorter and contain an inner IP header with the host's real network address. The memmove path processes this data, and the stale mlen causes the inner IP header (including the host's real IP) to be included in the echo reply sent back to the guest. This breaks the NAT isolation that slirp user-mode networking provides.
The attack requires the guest to ping a nonexistent host on the hypervisor's local network while SOCKDGRAM ICMP is restricted (which forces the raw socket fallback). No authentication or special privileges are needed on the guest side.
The leaked information is the host's real IP address (4 bytes of network metadata), not arbitrary host heap memory as originally reported.
Upstream fix: https://gitlab.freedesktop.org/slirp/libslirp/-/commit/262c9be27bc79e16b369807b460be77e23c3d788 Upstream issue: https://gitlab.freedesktop.org/slirp/libslirp/-/workitems/105
Reported by: Piyusha Akash (manifoldoperations) via PSIRTSUPT-26209
A flaw was found in libslirp. The DHCPv6 (src/dhcpv6.c) and TFTP (src/tftp.c) response builders write guest-influenced, variable-length data into a reply mbuf sized according to SlirpConfig.ifmtu, without checking that the write stays within that buffer. In dhcpv6inforequest(), a guest-supplied DHCPv6 CLIENTID option (up to 256 bytes, capped independently of ifmtu) is memcpy'd into the reply with no bounds check against the mbuf's actual size, overflowing the heap buffer whenever ifmtu is smaller than the clientid length plus fixed overhead. A related sink in the same function computes a signed 'smaxlen' for the boot-file-URL option that can go negative once earlier options have consumed the MTU window, which, when passed as an unsigned size to slirpfmt(), defeats its length truncation entirely. An analogous pattern exists in tftpreaddata() (src/tftp.c) via the guest-supplied blksize option. These sinks are only reachable when the host/hypervisor operator has configured a small interface MTU (below the IPv6 minimum link MTU of 1280, down to the library's accepted floor of 68); the default MTU of 1500 is not affected.
A flaw was found in libslirp. The DHCPv6 (src/dhcpv6.c) and TFTP (src/tftp.c) response builders write guest-influenced, variable-length data into a reply mbuf sized according to SlirpConfig.ifmtu, without checking that the write stays within that buffer. In dhcpv6inforequest(), a guest-supplied DHCPv6 CLIENTID option (up to 256 bytes, capped independently of ifmtu) is memcpy'd into the reply with no bounds check against the mbuf's actual size, overflowing the heap buffer whenever ifmtu is smaller than the clientid length plus fixed overhead. A related sink in the same function computes a signed 'smaxlen' for the boot-file-URL option that can go negative once earlier options have consumed the MTU window, which, when passed as an unsigned size to slirpfmt(), defeats its length truncation entirely. An analogous pattern exists in tftpreaddata() (src/tftp.c) via the guest-supplied blksize option. These sinks are only reachable when the host/hypervisor operator has configured a small interface MTU (below the IPv6 minimum link MTU of 1280, down to the library's accepted floor of 68); the default MTU of 1500 is not affected.