QEMU: guest-triggered out-of-bounds write when a physical memory map returns short

CVE-2026-3842Kernel, userspace & hypervisorcurated

Impact

A local attacker inside a guest can cause QEMU to write past an allocation when cpu_physical_memory_map() returns a shorter length than the caller expected. The write lands in the QEMU process heap on the host, so the consequences range from guest memory disclosure and heap corruption to killing the VM. On a GPU cloud that rents whole VMs with passed-through accelerators, the QEMU process is the tenant boundary, and corrupting it is the first step of a guest-to-host escape. Red Hat rates it 7.8 local with high confidentiality, integrity and availability impact; the record does not claim a working escape.

Who can reach it

A local user inside a guest VM - that is, any tenant who has been handed a virtual machine. No host credentials and no access to the management network are needed.

What to do

Install the fixed qemu-kvm packages from your distribution (Red Hat tracks this across RHEL 6 through 10 and OpenShift Container Platform 4). The running QEMU process keeps the old code, so each guest has to be live-migrated or stopped and restarted before it is actually protected - in practice, drain the node's VMs onto patched hosts rather than patching in place and assuming it took effect.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-3842 https://access.redhat.com/security/cve/CVE-2026-3842 https://bugzilla.redhat.com/show_bug.cgi?id=2458150

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.