REDHAT-BUG-2537748: Medium severity libslirp libslirp vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Configure if_mtu to at least 1280; the vulnerable sinks are reachable when the interface MTU is below 1280.
SlirpConfig if_mtu = 1280 or greater
Event History
Frequently Asked Questions
Which deployments are exposed?
Only deployments where the host or hypervisor operator configured libslirp with an interface MTU below 1280 are exposed. The default MTU of 1500 is not affected.
What does an attacker need to exploit this?
An attacker needs to control a guest using the affected slirp network interface and provide oversized DHCPv6 CLIENTID data or a TFTP blksize option. Reachability also depends on the operator having configured the small interface MTU.
What can be done before a fix is available?
Avoid interface MTU values below 1280 for libslirp-backed networking. In particular, do not use the accepted low MTU range down to 68 where these response-building paths can exceed the reply buffer.
How can I determine whether my environment is affected?
Check the SlirpConfig.if_mtu value used by the host or hypervisor for libslirp networking. Systems using the default value of 1500 are not affected; configurations below 1280 should be treated as exposed.