CVE-2026-64561

Published Aug 4, 2026

Last updated 2 days ago

CVSS high 8.8
Linux Kernel
Zapscape

Overview

AI description

Automated description summarized from trusted sources.

CVE-2026-64561, dubbed "Zapscape," is a use-after-free vulnerability found in the Linux kernel's KVM virtualization code, specifically within the x86 shadow memory management unit (MMU). Discovered by researcher Hyunwoo Kim (@v4bel), the flaw stems from an incorrect ordering in page-fault handling. KVM checks the validity of the shadow MMU root before making MMU pages available; however, if shadow-page reclamation invalidates the in-use root during the subsequent page availability process, KVM can proceed to map memory using this now-stale root. This leads to the creation of invalid child shadow pages that are still added to the active MMU page list, violating KVM MMU invariants. Under specific conditions, such as when nested virtualization is enabled and an attacker has kernel-level control within a KVM guest, this vulnerability can be exploited to achieve a guest-to-host escape, allowing the attacker to execute code with root privileges on the host system. A public proof-of-concept exploit exists for Zapscape, which affects Linux kernels from version 5.9 onward.

Description
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a "stale" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is "fine", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, "KVM: MMU: ignore zapped root pagetables"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Received

Risk scores

CVSS 3.1

Type
Secondary
Base score
8.8
Impact score
6
Exploitability score
2
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Severity
HIGH

Social media

Hype score
Not currently trending

  1. CVE-2026-64561 Zapscape permite a invitados KVM escapar al host Linux con privilegios root Se ha descubierto una vulnerabilidad en el núcleo de Linux llamada Zapscape (CVE-2026-64561) https://t.co/Lks4hcDVvl

    @elhackernet

    10 Aug 2026

    4718 Impressions

    12 Retweets

    49 Likes

    10 Bookmarks

    0 Replies

    0 Quotes

  2. CVE-2026-64561 https://t.co/oznSUBX0s9

    @Mas73r

    7 Aug 2026

    29 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. PoC exploit code is public for CVE-2026-64561 (Zapscape), a KVM escape that runs commands with kernel root privilege on the host. Details inside. #KVM #Linux #CVE #Virtualization #CyberSecurity https://t.co/yDJEahiWID

    @Daily_CyberSec

    7 Aug 2026

    477 Impressions

    4 Retweets

    7 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. Zapscape (CVE-2026-64561) in Linux KVM/x86 shadow-MMU can let a privileged L1 guest escape to the host and run code as root. Upstream fix already merged. #Zapscape #CVE-2026-64561 #KVM https://t.co/JdrLAdqFkP

    @TweetThreatNews

    6 Aug 2026

    207 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. 🚨 Linux KVM'de yeni kritik VM Escape açığı duyuruldu ve PoC yayınlandı! Zapscape (CVE-2026-64561) adı verilen yeni güvenlik açığı, duyurulduktan bir kaç gün sonra PoC GitHub'da kamuya açık olarak paylaşıldı. PoC: https://t.co/guR6FIaQAJ Açık, nested vir

    @ridvanyagli

    6 Aug 2026

    1528 Impressions

    8 Retweets

    25 Likes

    11 Bookmarks

    0 Replies

    0 Quotes

  6. 🚨 Linux KVM'de yeni kritik VM Escape açığı duyuruldu ve PoC yayınlandı! Zapscape (CVE-2026-64561) adı verilen yeni güvenlik açığını duyuruldu ve hemen ardından PoC GitHub'da kamuya açık olarak paylaşıldı. PoC: https://t.co/guR6FIaiLb Açık, nested virtua

    @ridvanyagli

    6 Aug 2026

    21 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. 🚨 Linux KVM'de yeni kritik VM Escape açığı duyuruldu ve PoC yayımlandı! Zapscape (CVE-2026-64561) adı verilen yeni güvenlik açığını duyuruldu ve hemen ardından PoC GitHub'da kamuya açık olarak paylaşıldı. PoC: https://t.co/guR6FIaQAJ Açık, nested virtua

    @ridvanyagli

    6 Aug 2026

    15 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. 🚨 Linux KVM'de yeni kritik VM Escape açığı duyuruldu ve PoC yayımlandı! Zapscape (CVE-2026-64561) adı verilen yeni güvenlik açığını duyuruldu ve hemen ardından PoC GitHub'da kamuya açık olarak paylaşıldı. Açık, nested virtualization etkin olan KVM sistem

    @ridvanyagli

    6 Aug 2026

    20 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  9. 🚨*CVE* CVE-2026-64561 In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a "stale"… https://t.co/VFWf5wAfub ----- Traducción: CVE-2026-64561 En … https://t.co/utmtNg

    @infoflowcloud

    4 Aug 2026

    33 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Related CVEs

  1. In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).•CVE-2026-63801
  2. In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.•CVE-2026-46316
  3. In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.•CVE-2026-46243
  4. In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ]•CVE-2026-43499
  5. In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.•CVE-2026-46333

References

Sources include official advisories and independent security research.