https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 17:58:35 +0000 https://db.gcve.eu/vuln/bdu:2026-03697 bdu:2026-03697 https://db.gcve.eu/vuln/bdu:2026-03697 https://db.gcve.eu/vuln/certfr-2025-avi-0252 certfr-2025-avi-0252 https://db.gcve.eu/vuln/certfr-2025-avi-0252 https://db.gcve.eu/vuln/fkie_cve-2022-49562 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits</p> <p>Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing &#34;random&#34; pfns for pretty much any other VM_PFNMAP case.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits</p> <p>Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing &#34;random&#34; pfns for pretty much any other VM_PFNMAP case.</p> https://db.gcve.eu/vuln/fkie_cve-2022-49562 https://db.gcve.eu/vuln/ghsa-xpvw-h2w8-vrf9 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits</p> <p>Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing &#34;random&#34; pfns for pretty much any other VM_PFNMAP case.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits</p> <p>Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing &#34;random&#34; pfns for pretty much any other VM_PFNMAP case.</p> https://db.gcve.eu/vuln/ghsa-xpvw-h2w8-vrf9 https://db.gcve.eu/vuln/msrc_cve-2022-49562 msrc_CVE-2022-49562 https://db.gcve.eu/vuln/msrc_cve-2022-49562 https://db.gcve.eu/vuln/rhsa-2023:2458 <p>security update for kernel</p> <p>security update for kernel</p> https://db.gcve.eu/vuln/rhsa-2023:2458 https://db.gcve.eu/vuln/suse-su-2025:1027-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://db.gcve.eu/vuln/suse-su-2025:1027-1 https://db.gcve.eu/vuln/ubuntu-cve-2022-49562 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 133 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing &#34;random&#34; pfns for pretty much any other VM_PFNMAP case.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 133 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing &#34;random&#34; pfns for pretty much any other VM_PFNMAP case.</p> https://db.gcve.eu/vuln/ubuntu-cve-2022-49562