https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 22:03:22 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-01008 bdu:2025-01008 https://cve.radiocsirt.org/vuln/bdu:2025-01008 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0963 certfr-2024-avi-0963 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0963 https://cve.radiocsirt.org/vuln/euvd-2026-207911 EUVD-2026-207911 https://cve.radiocsirt.org/vuln/euvd-2026-207911 https://cve.radiocsirt.org/vuln/fkie_cve-2024-45818 <p>The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in &#34;standard&#34; mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren&#39;t relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock.</p> <p>This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work.</p> <p>In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.</p> <p>The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in &#34;standard&#34; mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren&#39;t relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock.</p> <p>This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work.</p> <p>In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-45818 https://cve.radiocsirt.org/vuln/ghsa-9ppw-wh7x-2qc9 <p>The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in &#34;standard&#34; mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren&#39;t relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock.</p> <p>This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work.</p> <p>In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.</p> <p>The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in &#34;standard&#34; mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren&#39;t relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock.</p> <p>This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work.</p> <p>In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.</p> https://cve.radiocsirt.org/vuln/ghsa-9ppw-wh7x-2qc9 https://cve.radiocsirt.org/vuln/opensuse-su-2024:14530-1 <p>xen-4.19.0_06-1.1 on GA media</p> <p>xen-4.19.0_06-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:14530-1 https://cve.radiocsirt.org/vuln/suse-su-2024:3977-1 <p>Security update for xen</p> <p>Security update for xen</p> https://cve.radiocsirt.org/vuln/suse-su-2024:3977-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-45818 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: xen, Ubuntu:18.04:LTS: xen, Ubuntu:20.04:LTS: xen, Ubuntu:22.04:LTS: xen, Ubuntu:24.04:LTS: xen, Ubuntu:25.10: xen, Ubuntu:26.04:LTS: xen</p> <p>The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in &#34;standard&#34; mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren&#39;t relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock. This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work. In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: xen, Ubuntu:18.04:LTS: xen, Ubuntu:20.04:LTS: xen, Ubuntu:22.04:LTS: xen, Ubuntu:24.04:LTS: xen, Ubuntu:25.10: xen, Ubuntu:26.04:LTS: xen</p> <p>The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in &#34;standard&#34; mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren&#39;t relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock. This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work. In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-45818 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3410 <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Xen ausnutzen, um Informationen offenzulegen oder einen Denial of Service zu verursachen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Xen ausnutzen, um Informationen offenzulegen oder einen Denial of Service zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3410