Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

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.if_mtu, without checking that the write stays within that buffer. In dhcpv6_info_request(), a guest-supplied DHCPv6 CLIENTID option (up to 256 bytes, capped independently of if_mtu) is memcpy'd into the reply with no bounds check against the mbuf's actual size, overflowing the heap buffer whenever if_mtu is smaller than the client_id 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 slirp_fmt(), defeats its length truncation entirely. An analogous pattern exists in tftp_read_data() (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.