CVE-2026-95508: Libslirp: libslirp: heap buffer overflow in dhcpv6/tftp response builders on small interface mtu
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.
Other sources
A heap-based buffer overflow was found in the DHCPv6 and TFTP response builders of libslirp. When the host is configured with a small interface MTU, a guest-supplied DHCPv6 CLIENTID option or TFTP blksize option can overflow the reply buffer with attacker-controlled content and length, resulting in denial of service and potentially arbitrary code execution in the host process. The default interface MTU is not affected.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Configure the interface MTU to at least 1280 to avoid the small-MTU condition that enables the DHCPv6 and TFTP response-buffer overflows.
libslirp SlirpConfig.if_mtu = 1280
Event History
Frequently Asked Questions
Who is exposed to exploitation?
Deployments using libslirp are exposed only when the host or hypervisor operator has configured the Slirp interface MTU below 1280. A guest can reach the affected DHCPv6 and TFTP response-building paths using guest-influenced DHCPv6 CLIENTID or TFTP blksize values.
Are default configurations affected?
No. The default interface MTU of 1500 is not affected; the vulnerable paths require a deliberately small configured MTU, with the library accepting values as low as 68.
What can be done if patching is not immediately possible?
Set the Slirp interface MTU to at least 1280, rather than using a value below the IPv6 minimum link MTU. This prevents the described sinks from being reachable under the stated conditions.
How can an operator determine whether their deployment is affected?
Check the SlirpConfig.if_mtu value used by the host or hypervisor. An affected configuration has an interface MTU below 1280; a value of 1500 is not affected by this issue.