Loading vulnerability…
Firecracker snapshot memory-discard guest-to-VMM escape
Firecracker versions 0.23.0 through 1.16.1 contain a stale-memory-reference vulnerability affecting microVMs restored from snapshots using the File memory backend with a balloon or virtio-mem device. During guest-requested memory discard, Firecracker uses MAP_FIXED to replace snapshot-backed memory with anonymous memory at the same host virtual address. If the original mapping is removed but the replacement fails, KVM can retain an active memory slot referencing the unmapped range. Firecracker continues running and may reuse that range for its own allocations, allowing a root user inside the guest to read or modify live VMM process memory. Exploitation has demonstrated controlled code execution in Firecracker's EventManager.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation compromises the confidentiality and integrity of the host-side Firecracker VMM process and can provide code execution across the guest-to-VMM isolation boundary. This does not by itself establish unrestricted host access or host-kernel code execution: existing process credentials, seccomp filtering, chroot, and namespace restrictions remain relevant. Further host operations and a host-kernel panic were demonstrated only through chains involving independent weaknesses. AWS services, including AWS Lambda, are unaffected.
If you can’t patch tonight, do this now.
If upgrading is not immediately possible, restore snapshots using the Uffd memory backend and follow its documented discarded-page handling requirements. Keep the memory cgroup OOM killer enabled to address known host-memory failure conditions. On kernels lacking the Linux 6.12 overcommit-handling change, configure heuristic overcommit with vm.overcommit_memory=0 and limit the maximum discard size to no more than total host RAM plus swap. These host-memory measures do not prevent every possible replacement-mapping failure and are not substitutes for upgrading.
Patch, then assume compromise.
Upgrade Firecracker to version 1.16.2, 1.17.0, or later. Maintainers of forks or derivative implementations should incorporate the corresponding fixes from Firecracker PR #6174, which preserve the intended mapping properties and terminate Firecracker if a destructive replacement fails. No customer action is required for unaffected AWS services.
No public exploits tracked yet. Mallory keeps watching.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.