ブログ詳細

<p><strong>News Date: 2026-08-06</strong></p><p>A newly disclosed Linux kernel vulnerability demonstrates why nested virtualization should be treated as a meaningful expansion of the host attack surface. Named Zapscape and tracked as CVE-2026-64561, the flaw affects KVM's handling of shadow memory-management structures and can create a path from a privileged nested guest to the underlying host.</p><h2>How the Isolation Failure Occurs</h2><p>KVM uses shadow page tables to manage memory translation in certain nested virtualization configurations. During guest-triggered page-fault processing, KVM may reclaim memory-management pages and invalidate a root page that is still being used by the active fault-handling path.</p><p>The vulnerable code checks whether the root is stale before performing an operation that can reclaim and invalidate it. It then continues without repeating the check. This ordering problem can produce a use-after-free condition and leave references to memory that has already been released.</p><p>The public proof of concept uses the resulting corruption primitive to create a root-owned file on the host. Successful exploitation requires kernel-level privileges inside the first-level guest, which generally means that the attacker already controls that guest as root. This limits the range of immediately vulnerable environments, but it is important for cloud providers, hosting companies, research platforms and enterprises that expose nested virtualization to tenants or other untrusted users.</p><h2>Updates Require Distribution-Level Verification</h2><p>The upstream correction moves the stale-root validation to a safer position. If memory reclamation invalidates the current root, KVM restarts the page-fault operation instead of continuing with an unsafe reference.</p><p>Administrators should not rely only on the visible kernel version when checking exposure. Enterprise Linux vendors frequently backport security fixes without adopting the newest upstream release number. The correct approach is to consult the security tracker and package advisory for the specific distribution.</p><h3>Recommended Actions</h3><ul><li>Identify hosts where nested virtualization is enabled.</li><li>Determine whether untrusted guests can obtain or already possess kernel privileges.</li><li>Install vendor kernels containing the upstream fix or an approved backport.</li><li>Disable nested virtualization where it is not operationally required.</li><li>Separate high-risk virtualization workloads from sensitive management infrastructure.</li></ul><p>I believe Zapscape is less a reason to abandon nested virtualization than a reminder to expose it deliberately. Virtual machine isolation is a security boundary, but every additional virtualization layer introduces complex state that must be patched, monitored and minimized.</p>