# Snapshotting our way to CVE-2026-9539

libslirp TCP urgent pointer checked against intermediate buffer size, not valid data, causing integer underflow and OOB read leaking 128KiB of receive buffer including prior allocation leftovers.

- Payout: Research
- Severity: high
- Program: libslirp
- Found by (vendor credit): Bruce Chen of STAR Labs SG Pte. Ltd, Shi Weiming of STAR Labs SG Pte. Ltd
- Write-up by: Jérémy Marchand
- Disclosed: 2026-10-26
- CVE: CVE-2026-9539
- Write-up quality: 7/10
- Original: http://blog.quarkslab.com/snapshotting-our-way-to-cve-2026-9539.html
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-quarkslab-com-snapshotting-our-way-to-cve-2026-9539-html
- Tags: area:oss domain:oss impact:data-leak kind:research platform:research sev:high tech:linux technique:fuzzing technique:source-review vuln:memory-corruption

**Target:** libslirp TCP stack (sosendoob)
**Root cause:** TCP urgent pointer validated against intermediate buffer size instead of valid socket data; reading more than available causes integer underflow, leading to excessive read from ring buffer.
**Steps:**
1. Set up a TCP connection to libslirp.
2. Send data with an urgent pointer value larger than the valid data in the socket buffer.
3. Trigger sosendoob; the urgent pointer check passes against intermediate buffer size, not valid data.
4. Integer underflow occurs (e.g., `8 - 2048` in uint32_t), causing read of more data than available.
5. Data is sent in multiple packets, leaking the entire 128KiB receive buffer, including leftovers from previous allocations.
**How found:** Authors built a LibAFL-Qemu based incremental snapshot fuzzer targeting libslirp's TCP state machine. They missed the bug due to lack of detection: ASAN blind to OOB within custom allocator. Later, using UBSAN integer overflow detection, they confirmed the underflow at socket.c:394.
**Exploitation:** An attacker with a TCP connection to libslirp can send crafted urgent data to trigger the underflow, causing the stack to send back the full receive buffer contents, potentially leaking sensitive data from other connections or prior allocations.
**Insight:** When fuzzing custom allocators, ASAN may not detect OOB accesses within the allocator's memory pool. Use UBSAN for integer underflows or manually poison/unpoison memory regions to catch such bugs.

## Proof of concept (copied exactly from the original report)

**UBSAN runtime error from sosendoob integer underflow**

```
../src/socket.c:394:15: runtime error: unsigned integer overflow: 8 - 2048 cannot be represented in type 'uint32_t' (aka 'unsigned int')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/socket.c:394:15
```