CVE-2026-99999 — PoC Exploit Repository

⚠️ This is a working exploit repository. It contains real exploit code that triggers the CVE-2026-99999 vulnerability in a live KVM/QEMU environment.

📚 For a safe, local-only simulation of the same attack chain, see CVE-2026-99999-analysis (no root, no network, pure Python — great for understanding the bug without a lab).

Vulnerability Summary

CVE-2026-99999 — Linux kernel IPv4 csum_start validation bug in the GSO segmentation path. A guest VM can leak ~32–64 bytes of host-kernel heap memory per outbound packet fragment.

CVSS 9.3 | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Affected kernels: All before fix commits:

• 5.10.272+, 5.15.223+, 6.1.190+, 6.12.113+, 6.18.57+, 7.2.11+

Attacker model: Unprivileged code inside a KVM guest VM.

---

Repository Layout

.
├── README.md                    ← This file
├── guest/
│   ├── exploit_guest.c          ← Exploit (guest side)
│   ├── Makefile
│   └── README.md
└── host/
    ├── receive_and_dump.py      ← Leak detector (host side)
    └── setup_bridge.sh          ← TAP bridge setup (host side)

---

Attack Chain

1. GUEST: build_crafted_packet()
   └── [virtio_net_hdr(csum_start=0)] + [Eth] + [IP] + [UDP] + [payload]
           ↑
           csum_start=0 → points at IP header, NOT transport header

2. GUEST → QEMU (vhost-user)
   └── Guest enqueues packet via TX virtqueue
   └── QEMU reads descriptor → pulls malicious frame

3. HOST KERNEL: GSO segmentation path
   └── skb_checksum_help() reads csum_start (0) and csum_offset (0)
   └── Writes checksum result to byte 0 = IHL byte

4. HOST KERNEL: IHL corruption
   └── IHL: 0x45 (IHL=5, 20 bytes) → 0x4F (IHL=15, 60 bytes)

5. HOST KERNEL: ip_do_fragment() OOB read
   └── Reads 60 bytes of "IP header" when only 20 bytes exist
   └── Bytes 20-60 are adjacent host-kernel heap memory!

6. HOST: Outbound fragment
   └── Each fragment contains ~32-64 bytes of host-kernel heap memory
   └── Captured by receive_and_dump.py on the host bridge

---

Build

Guest side

# vhost-user mode (default — full vhost-user protocol implementation)
gcc -Wall -Wextra -O2 -o exploit_guest guest/exploit_guest.c -lpthread -lrt

# TAP bypass mode (no vhost-user socket needed)
gcc -Wall -Wextra -DUSE_TAP -O2 -o exploit_guest guest/exploit_guest.c -lpthread -lrt

Host side

# Leak detector
pip3 install scapy
python3 host/receive_and_dump.py --help

---

Usage

Option A: vhost-user mode (recommended)

Requires:

• QEMU started with -netdev vhost-user,...
• Guest memory shared with QEMU via memfd or tmpfs
• Root in guest

# On the host — start QEMU with vhost-user (socket on shared filesystem)
qemu-system-x86_64 \
  -m 2G -smp 2 \
  -hda /path/to/guest.img \
  -netdev vhost-user,id=net0,chardev=char0 \
  -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 \
  -chardev socket,id=char0,path=/tmp/vhost.sock,server=on,wait=off \
  -enable-kvm \
  -nographic

# On the host — start the leak detector
sudo python3 host/receive_and_dump.py --interface tap0 --packets 20 --verbose

# In the guest
sudo ./exploit_guest --socket /tmp/vhost.sock -n 20 -v

Option B: TAP bypass mode

Requires:

• TAP device connected to host bridge
• Root or CAP_NET_RAW in guest
• bridge-nf-call-iptables=1 on host (for GSO path)

# On the host
sudo ip link add br0 type bridge
sudo ip link set br0 up
sudo ip addr add 10.0.0.1/24 dev br0
sudo ip tuntap add dev tap0 mode tap
sudo ip link set tap0 master br0
sudo ip link set tap0 up
python3 host/receive_and_dump.py --interface tap0 --packets 20 --verbose

# In the guest
gcc -DUSE_TAP -O2 -o exploit_guest guest/exploit_guest.c -lpthread -lrt
sudo ./exploit_guest --tap tap0 -n 20 -v

---

Technical Notes

vhost-user Memory Sharing

The exploit requires QEMU to be able to read the guest's TX virtqueue memory. Without shared memory, QEMU cannot read the descriptors — the packets are enqueued but never transmitted.

For testing, use one of:

# Option 1: memfd (QEMU ≥ 4.2, Linux ≥ 3.17)
# Pass -object memory-backend-memfd,id=mem0,share=on to QEMU

# Option 2: tmpfs
mkdir -p /mnt/guest-shared
mount -t tmpfs -o size=64M tmpfs /mnt/guest-shared
# Point SET_MEM_TABLE at this region

# Option 3: hugetlbfs
mount -t hugetlbfs -o pagesize=2M hugetlbfs /mnt/hugepages
# Use hugetlbfs region in SET_MEM_TABLE

GSO Path Prerequisites

The CVE trigger requires the host kernel to process the frame through the GSO segmentation path. This happens when:

• The frame has IP_MF (More Fragments) flag set — forcing fragmentation
• Checksum offload is enabled on the virtio-net device
• The frame is larger than the MTU (forcing GSO segmentation)

The exploit sets IP_MF in every packet to ensure GSO segmentation.

Detection

The host-side detector (receive_and_dump.py) identifies CVE-2026-99999 by:

1. Capturing packets on the bridge interface
2. Detecting corrupted IHL bytes (version_ihl & 0x0F > 5)
3. Reporting the excess bytes as potential kernel heap memory leaks

---

Files

guest/exploit_guest.c   ← Full vhost-user implementation (handshake + virtqueue + packet TX)
host/receive_and_dump.py ← Packet capture + leak detection on host
host/setup_bridge.sh    ← TAP bridge setup helper script

---

Troubleshooting

"Cannot connect to vhost-user socket"

• Make sure QEMU is running with vhost-user and the socket exists
• Check: ls -la /tmp/vhost.sock

"Host does not support VIRTIO_NET_F_CSUM"

• Your QEMU/KVM config doesn't have checksum offload enabled
• Add to QEMU: -device virtio-net-pci,netdev=net0,csum=off,host_csum=off — enable, not disable

"Host does NOT support VIRTIO_NET_F_CSUM" (exploit output)

• The host's vhost-user backend did not negotiate the checksum offload feature
• This is expected for some QEMU configurations
• Try the TAP bypass mode instead

No corrupted packets detected

• Ensure the host kernel is unpatched (before 5.10.272, 5.15.223, 6.1.190)
• Check: uname -r
• Ensure IP_MF flag is being set on outgoing packets
• Try running Wireshark on the host bridge to observe raw frames

Permission denied

• Guest: needs root or sudo
• Host: needs root or sudo for packet capture and TAP setup

---

Disclaimer

For authorised security research in isolated lab environments ONLY. Unauthorized use against systems you do not own or lack written permission to test is illegal. The authors accept no liability for misuse.