{"id":"CVE-2019-18423","aliases":["ALPINE-CVE-2019-18423","DEBIAN-CVE-2019-18423","DSA-4602-1","EUVD-2019-8192","GHSA-jvp4-26qw-rfm7","MGASA-2020-0113","SUSE-SU-2019:2961-1","SUSE-SU-2019:3297-1","SUSE-SU-2019:3309-1","SUSE-SU-2019:3310-1","UBUNTU-CVE-2019-18423"],"status":"published","title":"An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of...","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","severity":{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"primary","from":"nvd"},"epss":{"day":"2026-11-09","score":0.02059,"percentile":0.8146,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-193"],"published":"2019-10-31T13:36:27Z","modified":"2026-09-21T07:03:10Z","fixes":[{"ecosystem":"Alpine:v3.10","package":"xen","fixed_in":["4.12.1-r1"],"sources":["osv"]},{"ecosystem":"Alpine:v3.11","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.12","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.13","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.14","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.15","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.16","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.17","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.18","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.19","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.20","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.21","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.22","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.23","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.24","package":"xen","fixed_in":["4.13.0-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.8","package":"xen","fixed_in":["4.10.4-r1"],"sources":["osv"]},{"ecosystem":"Alpine:v3.9","package":"xen","fixed_in":["4.11.2-r1"],"sources":["osv"]},{"ecosystem":"Debian:12","package":"xen","fixed_in":["4.11.3+24-g14b62ab3e5-1"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"xen","fixed_in":["4.11.3+24-g14b62ab3e5-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"xen","fixed_in":["4.11.3+24-g14b62ab3e5-1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Alpine:v3.10","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.12.1-r1"}]}]},{"source":"osv","ecosystem":"Alpine:v3.11","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.12","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.13","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.14","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.15","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.16","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.17","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.18","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.19","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.20","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.21","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.22","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.23","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.13.0-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.8","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.10.4-r1"}]}]},{"source":"osv","ecosystem":"Alpine:v3.9","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"4.8"},{"fixed":"4.11.2-r1"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.3+24-g14b62ab3e5-1"}]}]},{"source":"osv","ecosystem":"Debian:13","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.3+24-g14b62ab3e5-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.3+24-g14b62ab3e5-1"}]}]},{"source":"osv","ecosystem":"Debian:9","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.8.5.final+shim4.10.4-1+deb9u12"}]}],"versions":["4.8.1-1+deb9u1","4.8.1-1+deb9u2","4.8.1-1+deb9u3","4.8.2+xsa245-0+deb9u1","4.8.3+comet2+shim4.10.0+comet3-1+deb9u4","4.8.3+comet2+shim4.10.0+comet3-1+deb9u4.1","4.8.3+comet2+shim4.10.0+comet3-1+deb9u5","4.8.3+xsa262+shim4.10.0+comet3-1+deb9u6","4.8.3+xsa262+shim4.10.0+comet3-1+deb9u7","4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8","4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9","4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10","4.8.5+shim4.10.2+xsa282-1+deb9u11"],"bundled":17},{"source":"osv","ecosystem":"Debian:10","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.3+24-g14b62ab3e5-1~deb10u1"}]}],"versions":["4.11.1+92-g6c33308a8d-2"],"bundled":17},{"source":"osv","ecosystem":"Mageia:7","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.1-1.mga7"}]}],"bundled":10},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP1","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.1_04-3.6.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP1","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.1_04-3.6.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:HPE Helion OpenStack 8","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_06-3.59.1"}]}],"bundled":15},{"source":"osv","ecosystem":"SUSE:OpenStack Cloud 8","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_06-3.59.1"}]}],"bundled":15},{"source":"osv","ecosystem":"SUSE:OpenStack Cloud Crowbar 8","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_06-3.59.1"}]}],"bundled":15},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 12 SP3","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_06-3.59.1"}]}],"bundled":15},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP3-LTSS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_06-3.59.1"}]}],"bundled":15},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP3-BCL","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_06-3.59.1"}]}],"bundled":15},{"source":"osv","ecosystem":"SUSE:Enterprise Storage 5","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_06-3.59.1"}]}],"bundled":15},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.10.4_08-3.28.1"}]}],"bundled":9},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.10.4_08-3.28.1"}]}],"bundled":9},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Desktop 12 SP4","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.3_02-2.20.1"}]}],"bundled":10},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Software Development Kit 12 SP4","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.3_02-2.20.1"}]}],"bundled":10},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP4","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.3_02-2.20.1"}]}],"bundled":10},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 12 SP4","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.3_02-2.20.1"}]}],"bundled":10},{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.5.1-0ubuntu1","4.5.1-0ubuntu2","4.6.0-1ubuntu1","4.6.0-1ubuntu2","4.6.0-1ubuntu4","4.6.0-1ubuntu4.1","4.6.0-1ubuntu4.2","4.6.0-1ubuntu4.3","4.6.5-0ubuntu1","4.6.5-0ubuntu1.1","4.6.5-0ubuntu1.2","4.6.5-0ubuntu1.4"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.9.0-0ubuntu3","4.9.0-0ubuntu4","4.9.2-0ubuntu1"]}],"products":[{"vendor":"debian","product":"debian_linux"},{"vendor":"fedoraproject","product":"fedora"},{"vendor":"xen","product":"xen"}],"references":[{"url":"http://xenbits.xen.org/xsa/advisory-301.html","tags":["x_refsource_MISC","x_transferred","Patch","Vendor Advisory","fix","report"]},{"url":"http://www.openwall.com/lists/oss-security/2019/10/31/4","tags":["mailing-list","x_refsource_MLIST","x_transferred","Mailing List","Patch","Third Party Advisory","fix","report"]},{"url":"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2BQKX7M2RHCWDBKNPX4KEBI3MJIH6AYZ/","tags":["vendor-advisory","x_refsource_FEDORA","x_transferred","web"]},{"url":"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5WWPW4BSZDDW7VHU427XTVXV7ROOFFW/","tags":["vendor-advisory","x_refsource_FEDORA","x_transferred","web"]},{"url":"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IZYATWNUGHRBG6I3TC24YHP5Y3J7I6KH/","tags":["vendor-advisory","x_refsource_FEDORA","x_transferred","web"]},{"url":"https://www.debian.org/security/2020/dsa-4602","tags":["vendor-advisory","x_refsource_DEBIAN","x_transferred","Third Party Advisory","advisory"]},{"url":"https://seclists.org/bugtraq/2020/Jan/21","tags":["mailing-list","x_refsource_BUGTRAQ","x_transferred","Mailing List","Third Party Advisory","advisory"]},{"url":"https://security.gentoo.org/glsa/202003-56","tags":["vendor-advisory","x_refsource_GENTOO","x_transferred","Third Party Advisory","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2019-18423"},{"url":"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2BQKX7M2RHCWDBKNPX4KEBI3MJIH6AYZ/"},{"url":"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I5WWPW4BSZDDW7VHU427XTVXV7ROOFFW/"},{"url":"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IZYATWNUGHRBG6I3TC24YHP5Y3J7I6KH/"},{"url":"https://github.com/advisories/GHSA-jvp4-26qw-rfm7"},{"url":"https://security.alpinelinux.org/vuln/CVE-2019-18423","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2019-18423","tags":["advisory"]},{"url":"https://advisories.mageia.org/MGASA-2020-0113.html","tags":["advisory"]},{"url":"https://bugs.mageia.org/show_bug.cgi?id=25782","tags":["report"]},{"url":"https://xenbits.xen.org/xsa/advisory-295.html","tags":["advisory"]},{"url":"https://xenbits.xen.org/xsa/advisory-296.html","tags":["advisory"]},{"url":"https://xenbits.xen.org/xsa/advisory-298.html","tags":["advisory"]},{"url":"https://xenbits.xen.org/xsa/advisory-299.html","tags":["advisory"]},{"url":"https://xenbits.xen.org/xsa/advisory-301.html","tags":["advisory","report"]},{"url":"https://xenbits.xen.org/xsa/advisory-302.html","tags":["advisory"]},{"url":"https://xenbits.xen.org/xsa/advisory-303.html","tags":["advisory"]},{"url":"https://xenbits.xen.org/xsa/advisory-304.html","tags":["advisory"]},{"url":"https://xenbits.xen.org/xsa/advisory-305.html","tags":["advisory"]},{"url":"https://xenbits.xen.org/xsa/advisory-306.html","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2019/suse-su-20192961-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1027519","tags":["report"]},{"url":"https://bugzilla.suse.com/1152497","tags":["report"]},{"url":"https://bugzilla.suse.com/1154448","tags":["report"]},{"url":"https://bugzilla.suse.com/1154456","tags":["report"]},{"url":"https://bugzilla.suse.com/1154458","tags":["report"]},{"url":"https://bugzilla.suse.com/1154460","tags":["report"]},{"url":"https://bugzilla.suse.com/1154461","tags":["report"]},{"url":"https://bugzilla.suse.com/1154464","tags":["report"]},{"url":"https://bugzilla.suse.com/1155945","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2018-12207","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-11135","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-18420","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-18421","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-18422","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-18423","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-18424","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-18425","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2019/suse-su-20193297-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1157888","tags":["report"]},{"url":"https://bugzilla.suse.com/1158003","tags":["report"]},{"url":"https://bugzilla.suse.com/1158004","tags":["report"]},{"url":"https://bugzilla.suse.com/1158005","tags":["report"]},{"url":"https://bugzilla.suse.com/1158006","tags":["report"]},{"url":"https://bugzilla.suse.com/1158007","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2019-19577","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-19578","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-19579","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-19580","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-19581","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-19582","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-19583","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2019/suse-su-20193309-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2019/suse-su-20193310-1/","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2019-18423","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2019-18423","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2019-18423","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","status":"published","published":"2019-10-31T13:36:27Z","modified":"2024-08-05T01:54:14.432Z","updated_at":"2026-11-02T14:32:24.110857Z"}],"euvd":[{"id":"EUVD-2019-8192","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","status":"published","published":"2019-10-31T13:36:27Z","modified":"2024-08-05T01:54:14Z","updated_at":"2026-11-03T02:40:28.293703Z"}],"ghsa":[{"id":"GHSA-jvp4-26qw-rfm7","title":"An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of...","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","status":"published","published":"2022-05-24T17:00:11Z","modified":"2023-03-29T18:30:28Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-193"],"updated_at":"2026-11-02T14:54:24.674255Z"}],"nvd":[{"id":"CVE-2019-18423","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","status":"published","published":"2019-10-31T14:15:11.137Z","modified":"2026-06-17T02:25:00.687Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"primary"},{"version":"2.0","score":8.5,"vector":"AV:N/AC:M/Au:S/C:C/I:C/A:C","level":"high","assessor":"primary"}],"cwes":["CWE-193"],"updated_at":"2026-11-02T14:05:32.982925Z"}],"osv":[{"id":"ALPINE-CVE-2019-18423","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","status":"published","published":"2019-10-31T14:15:11.137Z","modified":"2026-09-21T06:17:52.504152622Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:27:47.663013Z"},{"id":"CVE-2019-18423","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","status":"published","published":"2019-10-31T14:15:11.137Z","modified":"2026-04-16T04:32:53.431992015Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:44:11.673963Z"},{"id":"DEBIAN-CVE-2019-18423","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","status":"published","published":"2019-10-31T14:15:11.137Z","modified":"2026-09-21T07:03:10.207285139Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:45:31.867036Z"},{"id":"UBUNTU-CVE-2019-18423","description":"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-\u003emax_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-\u003emax_mapped_gfn will be updated using the original frame. It would be possible to set p2m-\u003emax_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-\u003emax_mapped_gfn is off-by-one allowing \"highest mapped + 1\" 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.","status":"published","published":"2019-10-31T14:15:00Z","modified":"2026-04-22T12:13:59.081038Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:54:20.325378Z"},{"id":"DSA-4602-1","title":"xen - security update","status":"published","published":"2020-01-13T00:00:00Z","modified":"2026-03-09T02:09:09.678718Z","updated_at":"2026-11-02T15:46:17.19998Z"},{"id":"MGASA-2020-0113","title":"Updated xen packages fix security vulnerability","description":"- Updated from 4.12.0 to 4.12.1\n- Device quarantine for alternate pci assignment methods [XSA-306]\n- x86: Machine Check Error on Page Size Change DoS [XSA-304, CVE-2018-12207]\n- TSX Asynchronous Abort speculative side channel [XSA-305, CVE-2019-11135]\n- VCPUOP_initialise DoS [XSA-296, CVE-2019-18420] (rhbz#1771368)\n- missing descriptor table limit checking in x86 PV emulation [XSA-298,\n  CVE-2019-18425] (rhbz#1771341)\n- Issues with restartable PV type change operations [XSA-299, CVE-2019-18421]\n  (rhbz#1767726)\n- add-to-physmap can be abused to DoS Arm hosts [XSA-301, CVE-2019-18423]\n  (rhbz#1771345)\n- passed through PCI devices may corrupt host memory after deassignment\n  [XSA-302, CVE-2019-18424] (rhbz#1767731)\n- ARM: Interrupts are unconditionally unmasked in exception handlers\n  [XSA-303, CVE-2019-18422] (rhbz#1771443)\n- Unlimited Arm Atomics Operations [XSA-295, CVE-2019-17349,\n  CVE-2019-17350] (rhbz#1720760)\n- fix HVM DomU boot on some chipsets\n- adjust grub2 workaround\n","status":"published","published":"2020-03-06T16:13:58Z","modified":"2026-04-16T04:42:08.790653739Z","updated_at":"2026-11-02T15:49:41.151324Z"},{"id":"SUSE-SU-2019:2961-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2018-12207: Untrusted virtual machines on Intel CPUs could exploit a race\n  condition in the Instruction Fetch Unit of the Intel CPU to cause a Machine\n  Exception during Page Size Change, causing the CPU core to be non-functional.\n  (bsc#1155945)\n- CVE-2019-11135: Aborting an asynchronous TSX operation on Intel CPUs with\n  Transactional Memory support could be used to facilitate sidechannel\n  information leaks out of microarchitectural buffers, similar to the\n  previously described 'Microarchitectural Data Sampling' attack. (bsc#1152497).\n- CVE-2019-18423: A malicious guest administrator may cause a hypervisor crash,\n  resulting in a Denial of Service (DoS). (bsc#1154460).\n- CVE-2019-18422: A malicious ARM guest might contrive to arrange for critical \n  Xen code to run with interrupts erroneously enabled. This could lead to data\n  corruption, denial of service, or possibly even privilege escalation. However\n  a precise attack technique has not been identified. (bsc#1154464)\n- CVE-2019-18424: An untrusted domain with access to a physical device can DMA \n  into host memory, leading to privilege escalation. (bsc#1154461).\n- CVE-2019-18421: A malicious PV guest administrator may have been able to\n  escalate their privilege to that of the host. (bsc#1154458).\n- CVE-2019-18425: 32-bit PV guest user mode could elevate its privileges to that \n  of the guest kernel. (bsc#1154456).\n- CVE-2019-18420: Malicious x86 PV guests may have caused a hypervisor crash, \n  resulting in a Denial of Service (Dos). (bsc#1154448)\n- Upstream bug fixes (bsc#1027519)\n","status":"published","published":"2019-11-12T18:17:44Z","modified":"2026-02-04T02:50:15.612933Z","updated_at":"2026-11-02T15:53:47.06185Z"},{"id":"SUSE-SU-2019:3297-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2019-19581: Fixed a potential out of bounds on 32-bit Arm (bsc#1158003 XSA-307).\n- CVE-2019-19582: Fixed a potential infinite loop when x86 accesses to bitmaps with \n  a compile time known size of 64 (bsc#1158003 XSA-307).\n- CVE-2019-19583: Fixed improper checks which could have allowed HVM/PVH guest userspace \n  code to crash the guest,leading to a guest denial of service (bsc#1158004 XSA-308).\n- CVE-2019-19578: Fixed an issue where a malicious or buggy PV guest could have caused\n  hypervisor crash resulting in denial of service affecting the entire host (bsc#1158005 XSA-309).\n- CVE-2019-19580: Fixed a privilege escalation where a malicious PV guest administrator \n  could have been able to escalate their privilege to that of the host (bsc#1158006 XSA-310).\n- CVE-2019-19577: Fixed an issue where a malicious guest administrator could have caused Xen \n  to access data structures while they are being modified leading to a crash (bsc#1158007 XSA-311). \n- CVE-2019-19579: Fixed a privilege escaltion where an untrusted domain with access \n  to a physical device can DMA into host memory (bsc#1157888 XSA-306).\n- CVE-2019-18420: Malicious x86 PV guests may have caused a hypervisor crash, \n  resulting in a denial of service (bsc#1154448 XSA-296)\n- CVE-2019-18425: 32-bit PV guest user mode could elevate its privileges to that \n  of the guest kernel. (bsc#1154456 XSA-298).\n- CVE-2019-18421: A malicious PV guest administrator may have been able to\n  escalate their privilege to that of the host. (bsc#1154458 XSA-299).\n- CVE-2019-18423: A malicious guest administrator may cause a hypervisor crash,\n  resulting in a denial of service  (bsc#1154460 XSA-301).\n- CVE-2019-18422: A malicious ARM guest might contrive to arrange for critical \n  Xen code to run with interrupts erroneously enabled. This could lead to data\n  corruption, denial of service, or possibly even privilege escalation. However\n  a precise attack technique has not been identified. (bsc#1154464 XSA-303)\n- CVE-2019-18424: An untrusted domain with access to a physical device can DMA \n  into host memory, leading to privilege escalation. (bsc#1154461 XSA-302).  \n- CVE-2018-12207: Untrusted virtual machines on Intel CPUs could exploit a race\n  condition in the Instruction Fetch Unit of the Intel CPU to cause a Machine\n  Exception during Page Size Change, causing the CPU core to be non-functional.\n  (bsc#1155945 XSA-304)  \n- CVE-2019-11135: Aborting an asynchronous TSX operation on Intel CPUs with\n  Transactional Memory support could be used to facilitate sidechannel\n  information leaks out of microarchitectural buffers, similar to the\n  previously described 'Microarchitectural Data Sampling' attack. (bsc#1152497 XSA-305).  \n","status":"published","published":"2019-12-13T17:31:37Z","modified":"2026-02-04T02:43:05.056983Z","updated_at":"2026-11-02T15:53:47.06185Z"},{"id":"SUSE-SU-2019:3309-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2019-19581: Fixed a potential out of bounds on 32-bit Arm (bsc#1158003 XSA-307).\n- CVE-2019-19582: Fixed a potential infinite loop when x86 accesses to bitmaps with \n  a compile time known size of 64 (bsc#1158003 XSA-307).\n- CVE-2019-19583: Fixed improper checks which could have allowed HVM/PVH guest userspace \n  code to crash the guest,leading to a guest denial of service (bsc#1158004 XSA-308).\n- CVE-2019-19578: Fixed an issue where a malicious or buggy PV guest could have caused\n  hypervisor crash resulting in denial of service affecting the entire host (bsc#1158005 XSA-309).\n- CVE-2019-19580: Fixed a privilege escalation where a malicious PV guest administrator \n  could have been able to escalate their privilege to that of the host (bsc#1158006 XSA-310).\n- CVE-2019-19577: Fixed an issue where a malicious guest administrator could have caused Xen \n  to access data structures while they are being modified leading to a crash (bsc#1158007 XSA-311). \n- CVE-2019-19579: Fixed a privilege escaltion where an untrusted domain with access \n  to a physical device can DMA into host memory (bsc#1157888 XSA-306).\n- CVE-2019-18423: A malicious guest administrator may cause a hypervisor crash,\n  resulting in a Denial of Service (DoS) (bsc#1154460 XSA-301). \n- CVE-2019-18422: A malicious ARM guest might contrive to arrange for critical \n  Xen code to run with interrupts erroneously enabled. This could lead to data\n  corruption, denial of service, or possibly even privilege escalation. However\n  a precise attack technique has not been identified. (bsc#1154464 XSA-303)\n","status":"published","published":"2019-12-16T13:52:39Z","modified":"2026-02-04T03:06:26.361462Z","updated_at":"2026-11-02T15:53:47.06185Z"},{"id":"SUSE-SU-2019:3310-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2019-19581: Fixed a potential out of bounds on 32-bit Arm (bsc#1158003 XSA-307).\n- CVE-2019-19582: Fixed a potential infinite loop when x86 accesses to bitmaps with \n  a compile time known size of 64 (bsc#1158003 XSA-307).\n- CVE-2019-19583: Fixed improper checks which could have allowed HVM/PVH guest userspace \n  code to crash the guest,leading to a guest denial of service (bsc#1158004 XSA-308).\n- CVE-2019-19578: Fixed an issue where a malicious or buggy PV guest could have caused\n  hypervisor crash resulting in denial of service affecting the entire host (bsc#1158005 XSA-309).\n- CVE-2019-19580: Fixed a privilege escalation where a malicious PV guest administrator \n  could have been able to escalate their privilege to that of the host (bsc#1158006 XSA-310).\n- CVE-2019-19577: Fixed an issue where a malicious guest administrator could have caused Xen \n  to access data structures while they are being modified leading to a crash (bsc#1158007 XSA-311). \n- CVE-2019-19579: Fixed a privilege escaltion where an untrusted domain with access \n  to a physical device can DMA into host memory (bsc#1157888 XSA-306).\n- CVE-2019-18423: A malicious guest administrator may cause a hypervisor crash,\n  resulting in a Denial of Service (DoS). (bsc#1154460).\n- CVE-2019-18424: An untrusted domain with access to a physical device can DMA \n  into host memory, leading to privilege escalation. (bsc#1154461).\n- CVE-2019-18422: A malicious ARM guest might contrive to arrange for critical \n  Xen code to run with interrupts erroneously enabled. This could lead to data\n  corruption, denial of service, or possibly even privilege escalation. However\n  a precise attack technique has not been identified. (bsc#1154464)\n","status":"published","published":"2019-12-16T13:53:18Z","modified":"2026-02-04T02:34:38.533657Z","updated_at":"2026-11-02T15:53:47.06185Z"}]}}