kvmCTF (Linux KVM hypervisor)

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Full VM escape │ $250,000 │ $251,000 Arbitrary memory write │ $100,000 │ $101,000 Arbitrary memory read │ $50,000 │ $51,000 Relative memory write │ $50,000 │ $51,000 Denial of service (null-ptr-deref under KASAN) │ $20,000 │ $21,000 Relative memory read │ $10,000 │ $11,000 Submit a vulnerability CVE history 5,198 Last 12 months 18,708 Lifetime Memory safety 55 % Denial of service 20 % Info disclosure 15 % Access control 5 % Latest advisories Loading the feed Overview KVM is the hypervisor under Google Cloud, AWS Nitro guests, most OpenStack deployments, Proxmox, oVirt and effectively every Linux-based virtualization product, which makes a guest-to-host escape here a multi-tenant cloud boundary failure rather than a single-machine bug. That is why Google prices a full VM escape at a quarter of a million dollars, the highest single figure anywhere on this site. kvmCTF is not a report-and-wait program: you are given a Debian 12.5 guest on a live Google instance whose host runs Linux v6.1.74 LTS on an Intel Xeon Gold 5222, with KASAN on or off as you prefer, and you have to demonstrate the escape against that machine. Only 0-days count, and the ladder runs from $10,000 for a relative memory read to $250,000 for the full escape. Read the freshness note below before committing weeks to it: the pinned host is still a kernel from early 2024 and the rules page has not moved with its sibling programs. sorona.xyz adds 1.25x on top of whatever Google awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope Upstream KVM in the Linux kernel as Google runs it: a stock v6.1.74 LTS host on an Intel Xeon Gold 5222, with the target available built with CONFIG_KASAN enabled or disabled. You are connected to a Debian 12.5 guest on a v6.1.0-21 kernel with the default Debian config, and the finding has to cross from that guest into the host. 0-day only, demonstrated live against the instance arch/x86/kvm in full: the VMX and SVM entry paths, VM-exit handling, and the vCPU state machine behind them Instruction emulation and the MMIO paths, where guest-controlled bytes are decoded and acted on by host kernel code MSR and CPUID handling, the emulated interrupt controllers (local APIC, IOAPIC and PIC), and the emulated timers Nested virtualization: the host's handling of a guest hypervisor's control structures, VMCS and VMCB state included The memory side: EPT and NPT, shadow paging, memslot management, and the translation from a guest physical address into host memory Hypercalls and the paravirtualised interfaces a guest can invoke directly, including asynchronous page faults, paravirtual EOI and steal-time accounting Out of scope QEMU vulnerabilities, excluded explicitly despite QEMU being the userspace half of the same stack The host-to-KVM direction, which is not the boundary this program prices CPU, DRAM and other hardware-based issues, the Spectre, MDS and Rowhammer families among them, which are not rewarded here Already-patched 1-day bugs, since the program buys 0-days demonstrated live Anything shown only against a locally built kernel rather than against Google's pinned instance Kernel subsystems outside KVM, which belong to kernelCTF or to the kernel's own security process rather than to this program Most-valued findings A full guest-to-host escape ending in code execution on the host. At $250,000 it is the single largest published figure on this site, and the exact failure that breaks multi-tenant cloud isolation. Memory corruption in instruction emulation or MMIO handling, where guest-controlled bytes are decoded by host kernel code. Memory safety is 55% of the recorded kernel bug distribution and this is its densest seam in KVM Nested-virtualization state confusion, where the host mishandles a guest hypervisor's control structures. Historically the shortest route from a read primitive to the $100,000 arbitrary-write rung EPT, shadow-paging and memslot defects that turn a guest physical address into host memory the guest has no business reaching, which is how an arbitrary or relative access actually materialises Hypercall and paravirt-interface bugs reachable directly from an unprivileged guest, with no device emulation in the path at all A host denial of service demonstrated as a null-pointer dereference under KASAN, the cheapest rung at $20,000 and still a full-host outage caused by an untrusted guest Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. The exploit has to be demonstrated live against Google's own instance: a written analysis or a local reproduction is not what this program buys 0-day only: a bug that is already patched upstream earns nothing here, however good the exploit is You must report the vulnerability to [email protected] within 7 days, which is an obligation the rules place directly on you QEMU vulnerabilities are not rewarded even though QEMU is the userspace half of the stack, and neither is the host-to-KVM direction CPU, DRAM and other hardware-rooted issues of the Spectre and Rowhammer kind are outside what this program pays for The pinned host is still v6.1.74 and the rules page has not been revised alongside kernelCTF's 2026-04-30 update, so confirm the instance actually responds before you plan work around it Disclosure Coordinated on the kernel's clock rather than Google's: the rules oblige you to notify [email protected] within seven days of the finding, so the upstream security process owns the fix and the eventual advisory. Because that obligation runs to a named third party on a fixed deadline, file directly and treat the seven days as hard. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability