libslirp Memory Safety Vulnerabilities

An out-of-bounds heap read in libslirp's icmp_forward_error() causes host memory to be copied into the ICMP error reply that libslirp sends back to a guest VM or container, disclosing adjacent heap contents across the virtualization boundary. Affected deployments are those using libslirp as their network backend - QEMU user-mode ('slirp') networking and rootless Podman's slirp4netns/slirp4netns-style networking - with packaged builds tracked for Red Hat Enterprise Linux 8, 9 and 10 and Red Hat OpenShift Container Platform 4 and 5. The flaw is scored 7.4 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) with confidentiality-only impact; no public exploit identified at time of analysis, and exploitation requires an attacker who already controls a guest or container on the emulated network and can emit traffic that drives libslirp down the ICMP error path.

Queue-pointer corruption in libslirp's if_output() lets a guest on a libslirp user-mode network crash the host-side networking process. When burst traffic forces a session to migrate from the fast queue to the batch queue, the code unlinks and reinserts an arbitrary packet via ifm->m_nextpkt instead of the session queue head, leaving the queue pointers inconsistent; the result is an availability-only denial of service (CVSS 6.5, AV:A/AC:L/PR:N/UI:N, C:N/I:N/A:H) with no confidentiality or integrity impact and no demonstrated code execution. Affected deployments are those actually running the slirp/slirp4netns backend - QEMU user networking and rootless Podman/OpenShift container networking among Red Hat Enterprise Linux 8, 9 and 10 and OpenShift Container Platform 4 and 5 - while bridge, tap or passt setups are out of scope. Exploitation requires the attacker to already control a guest attached to that virtual network; no public exploit code has been identified at time of analysis, and this is a medium-severity, availability-only issue rather than a top-priority emergency.