https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 19 Oct 2026 14:05:43 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-98863 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails</p> <p>Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.</p> <p>Note, both SVM and VMX (as of commit 11722439fb20 (&#34;KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit&#34;) ensure the request is cleared on VM-Exit (including the &#34;forced&#34; case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails</p> <p>Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.</p> <p>Note, both SVM and VMX (as of commit 11722439fb20 (&#34;KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit&#34;) ensure the request is cleared on VM-Exit (including the &#34;forced&#34; case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages.</p> https://db.gcve.eu/vuln/fkie_cve-2026-98863 https://db.gcve.eu/vuln/ghsa-8v5w-2f74-jcch <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails</p> <p>Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.</p> <p>Note, both SVM and VMX (as of commit 11722439fb20 (&#34;KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit&#34;) ensure the request is cleared on VM-Exit (including the &#34;forced&#34; case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails</p> <p>Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.</p> <p>Note, both SVM and VMX (as of commit 11722439fb20 (&#34;KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit&#34;) ensure the request is cleared on VM-Exit (including the &#34;forced&#34; case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages.</p> https://db.gcve.eu/vuln/ghsa-8v5w-2f74-jcch