https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 21:59:11 +0000 https://cve.radiocsirt.org/vuln/bdu:2020-01473 bdu:2020-01473 https://cve.radiocsirt.org/vuln/bdu:2020-01473 https://cve.radiocsirt.org/vuln/certfr-2019-avi-541 certfr-2019-avi-541 https://cve.radiocsirt.org/vuln/certfr-2019-avi-541 https://cve.radiocsirt.org/vuln/euvd-2026-58767 EUVD-2026-58767 https://cve.radiocsirt.org/vuln/euvd-2026-58767 https://cve.radiocsirt.org/vuln/fkie_cve-2019-18423 <p>An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of service via a XENMEM_add_to_physmap hypercall. p2m-&gt;max_mapped_gfn is used by the functions p2m_resolve_translation_fault() and p2m_get_entry() to sanity check guest physical frame. The rest of the code in the two functions will assume that there is a valid root table and check that with BUG_ON(). The function p2m_get_root_pointer() will ignore the unused top bits of a guest physical frame. This means that the function p2m_set_entry() will alias the frame. However, p2m-&gt;max_mapped_gfn will be updated using the original frame. It would be possible to set p2m-&gt;max_mapped_gfn high enough to cover a frame that would lead p2m_get_root_pointer() to return NULL in p2m_get_entry() and p2m_resolve_translation_fault(). Additionally, the sanity check on p2m-&gt;max_mapped_gfn is off-by-one allowing &#34;highest mapped + 1&#34; to be considered valid. However, p2m_get_root_pointer() will return NULL. The problem could be triggered with a specially crafted hypercall XENMEM_add_to_physmap{, _batch} followed by an access to an address (via hypercall or direct access) that passes the sanity check but cause p2m_get_root_pointer() to return NULL. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.</p> <p>An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of service via a XENMEM_add_to_physmap hypercall. p2m-&gt;max_mapped_gfn is used by the functions p2m_resolve_translation_fault() and p2m_get_entry() to sanity check guest physical frame. The rest of the code in the two functions will assume that there is a valid root table and check that with BUG_ON(). The function p2m_get_root_pointer() will ignore the unused top bits of a guest physical frame. This means that the function p2m_set_entry() will alias the frame. However, p2m-&gt;max_mapped_gfn will be updated using the original frame. It would be possible to set p2m-&gt;max_mapped_gfn high enough to cover a frame that would lead p2m_get_root_pointer() to return NULL in p2m_get_entry() and p2m_resolve_translation_fault(). Additionally, the sanity check on p2m-&gt;max_mapped_gfn is off-by-one allowing &#34;highest mapped + 1&#34; to be considered valid. However, p2m_get_root_pointer() will return NULL. The problem could be triggered with a specially crafted hypercall XENMEM_add_to_physmap{, _batch} followed by an access to an address (via hypercall or direct access) that passes the sanity check but cause p2m_get_root_pointer() to return NULL. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2019-18423 https://cve.radiocsirt.org/vuln/ghsa-jvp4-26qw-rfm7 <p>An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of service via a XENMEM_add_to_physmap hypercall. p2m-&gt;max_mapped_gfn is used by the functions p2m_resolve_translation_fault() and p2m_get_entry() to sanity check guest physical frame. The rest of the code in the two functions will assume that there is a valid root table and check that with BUG_ON(). The function p2m_get_root_pointer() will ignore the unused top bits of a guest physical frame. This means that the function p2m_set_entry() will alias the frame. However, p2m-&gt;max_mapped_gfn will be updated using the original frame. It would be possible to set p2m-&gt;max_mapped_gfn high enough to cover a frame that would lead p2m_get_root_pointer() to return NULL in p2m_get_entry() and p2m_resolve_translation_fault(). Additionally, the sanity check on p2m-&gt;max_mapped_gfn is off-by-one allowing &#34;highest mapped + 1&#34; to be considered valid. However, p2m_get_root_pointer() will return NULL. The problem could be triggered with a specially crafted hypercall XENMEM_add_to_physmap{, _batch} followed by an access to an address (via hypercall or direct access) that passes the sanity check but cause p2m_get_root_pointer() to return NULL. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.</p> <p>An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of service via a XENMEM_add_to_physmap hypercall. p2m-&gt;max_mapped_gfn is used by the functions p2m_resolve_translation_fault() and p2m_get_entry() to sanity check guest physical frame. The rest of the code in the two functions will assume that there is a valid root table and check that with BUG_ON(). The function p2m_get_root_pointer() will ignore the unused top bits of a guest physical frame. This means that the function p2m_set_entry() will alias the frame. However, p2m-&gt;max_mapped_gfn will be updated using the original frame. It would be possible to set p2m-&gt;max_mapped_gfn high enough to cover a frame that would lead p2m_get_root_pointer() to return NULL in p2m_get_entry() and p2m_resolve_translation_fault(). Additionally, the sanity check on p2m-&gt;max_mapped_gfn is off-by-one allowing &#34;highest mapped + 1&#34; to be considered valid. However, p2m_get_root_pointer() will return NULL. The problem could be triggered with a specially crafted hypercall XENMEM_add_to_physmap{, _batch} followed by an access to an address (via hypercall or direct access) that passes the sanity check but cause p2m_get_root_pointer() to return NULL. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.</p> https://cve.radiocsirt.org/vuln/ghsa-jvp4-26qw-rfm7 https://cve.radiocsirt.org/vuln/gsd-2019-18423 gsd-2019-18423 https://cve.radiocsirt.org/vuln/gsd-2019-18423 https://cve.radiocsirt.org/vuln/suse-su-2019:2961-1 <p>Security update for xen</p> <p>Security update for xen</p> https://cve.radiocsirt.org/vuln/suse-su-2019:2961-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2019-18423 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: xen, Ubuntu:18.04:LTS: xen</p> <p>An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of service via a XENMEM_add_to_physmap hypercall. p2m-&gt;max_mapped_gfn is used by the functions p2m_resolve_translation_fault() and p2m_get_entry() to sanity check guest physical frame. The rest of the code in the two functions will assume that there is a valid root table and check that with BUG_ON(). The function p2m_get_root_pointer() will ignore the unused top bits of a guest physical frame. This means that the function p2m_set_entry() will alias the frame. However, p2m-&gt;max_mapped_gfn will be updated using the original frame. It would be possible to set p2m-&gt;max_mapped_gfn high enough to cover a frame that would lead p2m_get_root_pointer() to return NULL in p2m_get_entry() and p2m_resolve_translation_fault(). Additionally, the sanity check on p2m-&gt;max_mapped_gfn is off-by-one allowing &#34;highest mapped + 1&#34; to be considered valid. However, p2m_get_root_pointer() will return NULL. The problem could be triggered with a specially crafted hypercall XENMEM_add_to_physmap{, _batch} followed by an access to an address (via hypercall or direct access) that passes the sanity check but cause p2m_get_root_pointer() to return NULL. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: xen, Ubuntu:18.04:LTS: xen</p> <p>An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of service via a XENMEM_add_to_physmap hypercall. p2m-&gt;max_mapped_gfn is used by the functions p2m_resolve_translation_fault() and p2m_get_entry() to sanity check guest physical frame. The rest of the code in the two functions will assume that there is a valid root table and check that with BUG_ON(). The function p2m_get_root_pointer() will ignore the unused top bits of a guest physical frame. This means that the function p2m_set_entry() will alias the frame. However, p2m-&gt;max_mapped_gfn will be updated using the original frame. It would be possible to set p2m-&gt;max_mapped_gfn high enough to cover a frame that would lead p2m_get_root_pointer() to return NULL in p2m_get_entry() and p2m_resolve_translation_fault(). Additionally, the sanity check on p2m-&gt;max_mapped_gfn is off-by-one allowing &#34;highest mapped + 1&#34; to be considered valid. However, p2m_get_root_pointer() will return NULL. The problem could be triggered with a specially crafted hypercall XENMEM_add_to_physmap{, _batch} followed by an access to an address (via hypercall or direct access) that passes the sanity check but cause p2m_get_root_pointer() to return NULL. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2019-18423