Imagine you are sitting in the back seat of a self-driving car. The car is designed so passengers cannot touch the steering wheel. But you discover you can reach through a gap in the partition, find the wire bundle connecting the wheel to the steering column, and splice in your own signal — just long enough to make one deliberate turn — then reconnect everything before the car notices. That is structurally what this Firecracker escape does: it locates the host thread's saved CPU state while that thread is inside a kernel system call, rewrites the return address and arguments, triggers a return, executes an arbitrary function as the host process, then restores everything so Firecracker keeps running normally. The committed claim is a full guest-to-host code execution escape from Firecracker microVMs, demonstrated as CVE-2026-99999. This is not a theoretical primitive or a side-channel leak — it is arbitrary code execution as root on the host, achieved from inside the guest, with the VM remaining operational afterward. The attack chain starts from a host-memory read/write primitive established in Part 1, then builds four resolver stages: locating the guest page in host physical memory via EPT walking, reverse-mapping that page to find the Firecracker process's page tables, identifying the live vCPU thread's ptregs frame during KVMRUN, and finally rewriting that frame to redirect execution through Firecracker's own code (a write(2) wrapper) before cleanly returning to the original path. The architecture is a multi-stage memory oracle chain, not a single bug exploitation. Each stage produces a validated artifact — guestpagehpa, hostpgd, firecrackerbase, framehpa — that feeds the next. The EPT resolver brute-forces candidate translation roots across host physical memory, validates them by checking a planted nonce in the target page, then uses the confirmed mapping to reverse-search host page tables for a process that maps the same physical page. ASLR is defeated by locating the ELF image in the recovered address space and computing the load bias from known code offsets. The frame finder then searches for a ptregs structure whose saved instruction pointer matches the expected KVMRUN ioctl continuation, cross-validated against seven independent consistency checks including syscall number, file descriptor range, segment selectors, and stack pointer translatability through the recovered PGD. The integrity of the demonstration is high for offensive security research. The payload is deliberately minimal — writing an 8-byte marker string to stderr — which makes the proof unambiguous without requiring complex tooling on the host side. The attack is fully reversible: three stack words are saved before modification and restored after execution. The VM remains SSH-accessible post-exploitation, which rules out race-condition artifacts or crash-based flukes. The seven-field frame validation table is the strongest piece of evidence that the authors found the right structure and not a stale copy. What we cannot assess from Part 2 alone is the reliability of the underlying memory primitive from Part 1 — the entire chain depends on that foundation. The reversibility is the most technically impressive and most dangerous aspect. Classical VM escapes tend to crash the hypervisor or leave obvious forensic traces. This one completes, cleans up after itself, and lets the vCPU thread rejoin its normal execution path. The xor eax,eax; ret gadget that zeros the return value before re-entering the ioctl continuation is a small detail that makes the difference between a detectable anomaly and an invisible one. Firecracker's own code is used against it — no shellcode injection, no ROP chain across unknown binaries, just redirecting existing function calls with their expected calling convention. The broader implication lands on the entire microVM isolation model. Firecracker is AWS Lambda's and Fargate's isolation boundary. If a guest-accessible memory primitive (the Part 1 prerequisite) can be turned into full host takeover in four deterministic resolution stages, then the security margin between 'memory safety bug' and 'complete escape' is thinner than the architecture suggests. The attack does not exploit a Firecracker logic bug — it exploits the structural fact that KVM stores userspace registers in host kernel memory while a thread is in a syscall, and that those registers dictate where execution resumes. Any VMM using KVMRUN has this surface. What remains open is how practical the Part 1 memory primitive is to obtain in production. The entire chain is deterministic once you have read/write access to host physical memory ranges, but that starting condition is the real gate. The authors also have not demonstrated persistence, lateral movement, or exfiltration beyond the marker write — escalation from 'write a string to stderr' to 'exfiltrate secrets from co-tenant VMs' is architecturally straightforward but undemonstrated. The CVE designation and Firecracker's documented architecture suggest coordinated disclosure, but patch status and affected version ranges are not stated in the published material.
