GPU VulnDB

Database/Kernel, userspace & hypervisor

Firecracker: failed memory remap lets a guest root user read or modify VMM process memory

CVSS 7.1CVE-2026-122192Kernel, userspace & hypervisorcurated

Impact

On a microVM restored from a snapshot with the File memory backend, a balloon or virtio-mem discard request that fails to recreate its replacement mapping can leave the guest with a view into the Firecracker VMM process's own memory, readable and writable. That is a guest-to-VMM boundary crossing: on a multi-tenant node running many microVMs per host, the VMM process holds the state that keeps one tenant's VM separate from the device backends and the host. GPU and accelerator fleets that use Firecracker for per-tenant sandboxes around inference or agent code are exposed wherever snapshot restore with the File backend is in use. Exploitation needs root inside the guest and depends on a host allocation failure, so it is not a reliable primitive, but the consequence is full read/write of VMM memory.

Who can reach it

A local user with root privileges inside a Firecracker guest, on a microVM restored from a snapshot using the File memory backend. No host credentials needed; the guest must be able to issue balloon or virtio-mem discard requests and the host must fail to create the replacement mapping.

What to do

Upgrade Firecracker to 1.16.2 or 1.17.0 or later; affected range is 0.23.0 through 1.16.1. The binary is per-VM, so rolling it out means replacing it and restarting or re-launching each microVM - running guests keep the old VMM. No host reboot required.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.