CVE-2026-9539: 
Linux Debian 脆弱性の分析と軽減

CVE-2026-9539 is an out-of-bounds heap read and integer underflow vulnerability in the TCP urgent data handling function (sosendoob) of freedesktop.org libslirp, a user-space TCP/IP stack commonly used in hypervisor environments such as QEMU. It affects all libslirp versions before v4.9.2 and was published on June 24, 2026, with the CVE assigned by STAR Labs. The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) with a changed scope, reflecting its cross-boundary impact from guest VM to host process (GitHub Advisory).

The root cause is an out-of-bounds read (CWE-125) combined with an integer underflow in the sosendoob function, which handles TCP urgent (out-of-band) data within libslirp. An attacker inside a guest VM can craft TCP segments with manipulated URG flags and urgent pointer values (ti_urp) that cause the host-side libslirp process to read beyond the intended heap buffer boundaries. This occurs because the urgent pointer arithmetic is not properly validated before use, allowing negative or excessively large offsets to be computed. The fix is available in commit 927bca7344e31fd58e2f7afaca784aad4400eb84 in the libslirp GitLab repository (GitHub Advisory, libslirp commit).

A privileged guest VM attacker (requiring root or CAP_NET_RAW capabilities within the guest) can exploit this vulnerability to leak gigabytes of sensitive heap memory from the host hypervisor process (e.g., QEMU). The impact is limited to confidentiality — there is no integrity or availability impact — but the leaked memory may contain cryptographic keys, credentials, other VMs' data, or other sensitive host-process information. The changed scope means the vulnerability crosses the guest-to-host security boundary, making it a meaningful VM escape-adjacent risk in multi-tenant or cloud environments (GitHub Advisory).

1. Gain privileged access in guest VM: Obtain root or CAP_NET_RAW capability within a guest VM running on a QEMU (or similar) host that uses a vulnerable version of libslirp (< v4.9.2).
2. Craft malicious TCP segments: Using raw socket access (enabled by CAP_NET_RAW), construct TCP segments with the URG flag set and manipulated urgent pointer (ti_urp) values designed to trigger integer underflow in the host's sosendoob function.
3. Send crafted segments: Transmit the crafted TCP segments through the guest's network interface, which is processed by the libslirp user-space TCP/IP stack on the host.
4. Trigger out-of-bounds read: The malformed urgent pointer causes sosendoob to compute an invalid buffer offset, resulting in the host process reading memory beyond the intended heap buffer.
5. Exfiltrate heap data: Collect the out-of-bounds heap data returned via the TCP connection, potentially leaking sensitive host-process memory including credentials, keys, or data from other VMs. Repeat to accumulate gigabytes of leaked memory (GitHub Advisory).

• Network: Unusual TCP segments originating from a guest VM with the URG flag set and anomalous or extreme urgent pointer values; high-volume TCP urgent data traffic from a single guest VM.
• Process: Unexpected memory growth or heap anomalies in the QEMU host process; crashes or errors in the libslirp sosendoob function visible in QEMU logs.
• Logs: QEMU or hypervisor logs showing repeated TCP urgent data processing errors or segmentation faults; guest VM generating abnormally high volumes of raw socket traffic.
• File System: Presence of raw socket tools (e.g., scapy, custom C binaries) in the guest VM that are not part of the standard workload.

The primary remediation is to update libslirp to version v4.9.2 or later, which contains the fix in commit 927bca7344e31fd58e2f7afaca784aad4400eb84. For environments that cannot immediately patch, administrators should restrict guest VM privileges by removing CAP_NET_RAW capabilities where not operationally required, and implement network segmentation to limit guest VM network access. Monitoring for anomalous TCP urgent data traffic from guest VMs can serve as a compensating control (GitHub Advisory, libslirp release).

The vulnerability was assigned by STAR Labs, suggesting it was discovered through security research. A brief mention appeared on Bluesky via an automated CVE tracking account shortly after disclosure. No significant vendor statements, researcher commentary, or media coverage beyond standard vulnerability database aggregation has been observed as of the disclosure date (GitHub Advisory).