Database/Kernel, userspace & hypervisor

Linux KVM x86: per-vCPU MMIO cache uses address space 0, letting a guest force bogus MMIO exits
Impact
The per-vCPU MMIO cache is tagged with a memslot generation but both the fill and validation paths call kvm_memslots(), which always selects address space 0 even when the vCPU is executing in SMM and using address space 1. An update to the SMM memslots can therefore leave a stale SMM-address-space entry looking valid after the vCPU returns to normal mode, and the guest can make an access to ordinary RAM be reported to userspace as KVM_EXIT_MMIO. When the VMM completes that exit through its RAM mapping, the backing page is written without passing through KVM's write-tracking path; if the page backs a nested EPT table, KVM may keep using shadow translations derived from the stale contents, which the WARN_ON_ONCE() in kvm_mmu_write_protect_fault() flags. On a GPU node running tenant VMs with passthrough or vGPU, this is a guest-triggered host-side memory-management inconsistency in the hypervisor that sits under every tenant on the box - the practical risk is host-side corruption of nested paging state rather than a demonstrated container escape, and it needs a guest that enters SMM plus memslot churn, so it is not a drive-by.
Who can reach it
A local, authenticated guest - any tenant who can boot their own VM image on a KVM host and execute in SMM while the VMM updates SMM memslots. No host account and no network access are needed; the host userspace VMM must complete the resulting MMIO exit.
What to do
Pick up the stable kernel fix that switches the MMIO cache fill and validation to the vCPU's active memslots (kvm_vcpu_memslots()); the stable commits are linked in the record. There is no runtime mitigation, so this is a host kernel upgrade: drain the GPU node, migrate or stop tenant VMs, reboot into the patched kernel. Nodes that do not expose SMM-capable guests or nested virtualization are far less interesting to patch urgently, but the fix still has to land with a reboot. No fixed mainline release number is stated in the record beyond the listed commits.
References
Related entries
- Erlang/OTP public_key: unbounded certificate policy tree lets a TLS peer exhaust the BEAM nodeCVE-2026-59251 · Erlang/OTP public_key pubkey_policy_tree (X.509 certificate policy validation)High
- libssh2: malicious SSH server can corrupt the heap of any client opening an SFTP sessionCVE-2026-66032 · libssh2 sftp_open() (src/sftp.c double free)High
- libssh2: pre-auth integer underflow crashes any client that negotiates AES-GCMCVE-2026-66033 · libssh2 ssh2_cipher_crypt() (src/openssl.c AES-GCM length underflow)High
- Linux kernel mlx5_core representor TC path + net/sched tc extension: The TC_SKB_EXT skb extension is not zeroedCVE-2021-47136 · Linux kernel mlx5_core representor TC path + net/sched tc extensionHigh
- Linux kernel (net/tls): When a BPF socket policy shrinks the plaintext after the ciphertext length was computed, kTLSCVE-2025-38608 · Linux kernel (net/tls)High
- Linux kernel io_uring zero-copy receive: desc->count underflow lets a recv overshoot its limitCVE-2025-40046 · Linux kernel io_uring/zcrx (desc->count double accounting in io_zcrx_recv_skb)High
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.