CVE-2026-95508: 
Linux Red Hat Analyse et atténuation des vulnérabilités

CVE-2026-95508 is a heap-based buffer overflow vulnerability in the DHCPv6 and TFTP response builders of libslirp, a user-space network stack library used by hypervisors and container runtimes. When a host is configured with a small interface MTU (below the IPv6 minimum link MTU of 1280), a guest can supply a crafted DHCPv6 CLIENTID option or TFTP blksize option that overflows the reply buffer with attacker-controlled content and length, potentially resulting in denial of service or arbitrary code execution in the host process. The vulnerability was disclosed on September 22, 2026, and affects Red Hat products including libslirp, container-tools:rhel8/libslirp, openshift/ose-rhel-coreos-8, and openshift/ose-rhel-coreos-9; the default MTU of 1500 is not affected. It carries a CVSS v3.1 base score of 7.4 (High) (Red Hat CVE, GitHub Advisory).

The root cause is an out-of-bounds write (CWE-787) in two separate code paths within libslirp. In src/dhcpv6.c, the dhcpv6_info_request() function memcpy's a guest-supplied DHCPv6 CLIENTID option (up to 256 bytes, capped independently of if_mtu) into a reply mbuf sized according to SlirpConfig.if_mtu, with no bounds check against the mbuf's actual size — overflowing the heap buffer when if_mtu is smaller than the client_id length plus fixed overhead. Additionally, a signed smaxlen variable for the boot-file-URL option can go negative once earlier options consume the MTU window, which when passed as an unsigned size to slirp_fmt() defeats its length truncation entirely; an analogous pattern exists in src/tftp.c via the guest-supplied blksize option. Exploitation requires the host/hypervisor operator to have configured SlirpConfig.if_mtu below 1280 (down to the library's accepted floor of 68), making this a network-reachable but configuration-dependent attack vector (Red Hat Bugzilla, Red Hat CVE).

Successful exploitation allows a guest virtual machine or container to crash the host process (denial of service) or potentially execute arbitrary code in the host process context, breaking the guest-to-host isolation boundary. Because libslirp runs in the host process of hypervisors (e.g., QEMU) and container runtimes, code execution could grant an attacker control over the host system and enable lateral movement to other guests or host resources. Confidentiality impact is rated None (no direct data disclosure), while integrity and availability impacts are both rated High (Red Hat CVE, GitHub Advisory).

As of the disclosure date (September 22, 2026), there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Red Hat CVE). The EPSS score is 0.0, reflecting very low current exploitation probability (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires a non-default host configuration (small interface MTU below 1280), which significantly limits the attack surface in practice.

1. Identify target environment: Determine whether the target hypervisor or container runtime uses libslirp for networking (e.g., QEMU with user-mode networking) and whether the host has configured SlirpConfig.if_mtu below 1280.
2. Craft malicious DHCPv6 packet: From within a guest VM or container, construct a DHCPv6 Information-Request packet containing an oversized CLIENTID option (up to 256 bytes) designed to exceed the reply mbuf size calculated from the small if_mtu value.
3. Trigger overflow via DHCPv6: Send the crafted DHCPv6 packet to the virtual network interface. The dhcpv6_info_request() function in src/dhcpv6.c will memcpy the oversized CLIENTID into the undersized reply buffer, overflowing the heap.
4. Alternatively, exploit via TFTP: Send a TFTP request with a crafted blksize option from within the guest, triggering the analogous overflow in tftp_read_data() in src/tftp.c.
5. Achieve denial of service or code execution: The heap overflow corrupts host process memory. Depending on heap layout and exploit sophistication, this may crash the host process (DoS) or, with additional heap-shaping techniques, redirect execution to attacker-controlled code in the host process (Red Hat Bugzilla, Red Hat CVE).

• Process: Unexpected crash or restart of the QEMU or container runtime host process (e.g., segmentation fault or abort signal from the libslirp-linked process).
• Logs: Host system logs (e.g., /var/log/messages, journalctl) showing SIGSEGV, SIGABRT, or heap corruption errors originating from the hypervisor or container runtime process.
• Network: Unusual or malformed DHCPv6 packets (oversized CLIENTID options) or TFTP requests with abnormal blksize values originating from guest network interfaces, observable via host-side packet capture on the virtual network bridge.
• File System: Core dump files generated by a crashed hypervisor process in the working directory or configured core dump path.

The primary workaround is to ensure SlirpConfig.if_mtu is not configured below the IPv6 minimum link MTU of 1280; the default MTU of 1500 is not affected by this vulnerability (Red Hat CVE). Additionally, consider implementing network access controls to restrict DHCPv6 and TFTP traffic from guest interfaces if those protocols are not required. A patch has been made available — users of affected Red Hat products (libslirp, container-tools:rhel8/libslirp, openshift/ose-rhel-coreos-8, openshift/ose-rhel-coreos-9) should apply vendor-provided updates as they become available (Red Hat Bugzilla, GitHub Advisory).

Red Hat acknowledged the vulnerability and credited Stuart Thomas for reporting it, publishing a CVE entry and Bugzilla ticket on September 22, 2026 (Red Hat CVE, Red Hat Bugzilla). No significant broader community commentary or media coverage has been observed at this time, consistent with the early disclosure stage and the non-default configuration requirement limiting immediate impact.