CVE-2026-95508: libslirp Buffer Overflow Vulnerability

CVE-2026-95508 Overview

CVE-2026-95508 is a heap-based buffer overflow [CWE-787] affecting the libslirp user-mode networking library. The flaw resides in the DHCPv6 and TFTP response builder routines. When the host interface is configured with a small Maximum Transmission Unit (MTU), a guest can supply a crafted DHCPv6 CLIENTID option or a TFTP blksize option that overflows the reply buffer with attacker-controlled content and length. Successful exploitation results in denial of service and may enable arbitrary code execution in the host process running the emulator. Systems using the default interface MTU are not affected.

Critical Impact
A guest virtual machine can corrupt heap memory in the host libslirp process, escaping the guest boundary and potentially executing code with the privileges of the emulator.

Affected Products

libslirp user-mode networking library (DHCPv6 and TFTP response builders)
Hypervisors and emulators that link libslirp for slirp-based guest networking (for example, QEMU with slirp)
Downstream distributions redistributing vulnerable libslirp builds (see the Red Hat CVE Summary)

Discovery Timeline

2026-09-22 - CVE-2026-95508 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-95508

Vulnerability Analysis

The vulnerability lies in how libslirp builds reply packets for two guest-facing services it emulates: DHCPv6 and TFTP. Both response builders allocate a heap buffer sized against the host interface MTU. When the MTU is configured smaller than the default, the buffer becomes too small to hold guest-influenced option data.

For DHCPv6, the CLIENTID option supplied by the guest is copied into the reply without validating the remaining buffer space against the option length. For TFTP, the blksize option negotiated by the guest client controls the size of subsequent data replies, and the builder writes past the allocated boundary. Both paths give the guest control over the written content and length, which is the classic pattern behind out-of-bounds writes categorized as [CWE-787].

Because libslirp runs inside the emulator process on the host, memory corruption crosses the guest-to-host trust boundary. The impact ranges from process crash (denial of service) to arbitrary code execution in the host user-mode process.

Root Cause

The reply buffer size is derived from the interface MTU without accounting for the maximum length of variable guest-supplied options. The builders assume MTU headroom that no longer exists when a small MTU is configured, and no bounds check is performed before copying option payloads.

Attack Vector

A local guest with the ability to send DHCPv6 or TFTP traffic to the emulated slirp stack can trigger the overflow. Because slirp is exposed to the guest network, no host-side authentication is required. Exploitation is constrained to environments where the host has explicitly configured a small interface MTU on the slirp network.

No verified exploit code examples are available for CVE-2026-95508. Technical detail is tracked in Red Hat Bug Report #2537748.

Detection Methods for CVE-2026-95508

Indicators of Compromise

Unexpected crashes or segmentation faults in emulator processes linked against libslirp, particularly correlated with guest network activity.
DHCPv6 packets from a guest containing oversized or malformed CLIENTID options.
TFTP option negotiation from a guest requesting an unusually large blksize value against a slirp interface with a reduced MTU.

Detection Strategies

Inventory hosts running hypervisors that link libslirp and identify configurations that set a non-default, reduced interface MTU on the slirp network.
Monitor emulator process telemetry for abnormal termination signals (SIGSEGV, SIGABRT) tied to libslirp stack frames.
Inspect guest-to-host DHCPv6 and TFTP flows for option fields that approach or exceed the negotiated MTU.

Monitoring Recommendations

Enable core dump collection for emulator processes to support post-crash triage referencing libslirp symbols.
Alert on repeated emulator restarts on the same host, which can indicate exploitation attempts against the corrupted heap.
Log slirp network configuration changes, especially MTU adjustments applied at VM launch.

How to Mitigate CVE-2026-95508

Immediate Actions Required

Identify all hosts using libslirp-backed guest networking and confirm whether any interface MTU has been reduced below the default.
Restore the default interface MTU on slirp networks where a smaller MTU is not required, which removes the exploitable condition.
Apply the vendor-supplied libslirp update as soon as it is available through your distribution package manager.

Patch Information

Refer to distribution advisories for fixed package versions. Tracking information is available in the Red Hat CVE Summary and Red Hat Bug Report #2537748. Rebuild or update any downstream emulators statically linking libslirp after upstream patches land.

Workarounds

Leave the slirp interface MTU at the default value; the default MTU is not affected.
Where feasible, replace slirp-based guest networking with virtio-net plus a tap interface or bridged networking, which does not rely on libslirp response builders.
Restrict untrusted workloads from running inside guests that use slirp networking until patched packages are deployed.

bash

# Configuration example: verify libslirp version and slirp MTU on QEMU hosts
rpm -q libslirp || dpkg -l | grep libslirp

# Inspect QEMU command lines for reduced MTU on user-mode networking
ps -eo cmd | grep -Eo '\-netdev[^ ]* user[^ ]*mtu=[0-9]+' || echo 'No custom slirp MTU detected'