Kata Container to Guest micro VM privilege escalation
Date: 2026-02
Affected: go/github.com/kata-containers/kata-containers/src/runtime
Attack vector: rce
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2026-24834
CWE: CWE-732

### Summary An issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM. The current understinding is this doesn’t impact the security of the Host or of other containers / VMs running on that Host (note that arm64 QEMU lacks NVDIMM read-only support: It is believed that until the upstream QEMU gains this capability, a guest write could reach the image file). ### Details _Linux virtio-pmem_ The `virtio-pmem` probe path always registers the region as a generic pagemap that supports asynchronous flushes, but it never marks the region as read-only. Only the `ND_REGION_PAGEMAP` and `ND_REGION_ASYNC` bits are set before the region is created, so `nd_region->ro always` stays cleared and the block device is left writable. Later, `pmem_attach_disk()` wires the region into the block layer with full read/write semantics – the block device operations call `pmem_do_write()` which performs cache-flushed memcpy operations directly into the host-provided shared memory window. `nvdimm_check_and_set_ro()` would set the disk read-only if the region had been flagged as such, but because `virtio_pmem` never sets that flag, the helper becomes a no-op. _Cloud-Hypervisor virtio_pmem_ `discard_writes=on` causes the file backing the `virtio-pmem` device to be opened read-only and mapped with `MAP_PRIVATE` rather than `MAP_SHARED`. That combination means the guest can mo


Mitigations:

Architectural layers (MAESTRO):