{"id":"CVE-2020-29483","aliases":["ALPINE-CVE-2020-29483","DEBIAN-CVE-2020-29483","DSA-4812-1","EUVD-2020-21851","GHSA-q89m-rx2c-6v2g","SUSE-SU-2020:14578-1","SUSE-SU-2020:3880-1","SUSE-SU-2020:3881-1","SUSE-SU-2020:3913-1","SUSE-SU-2020:3914-1","SUSE-SU-2020:3915-1","SUSE-SU-2020:3916-1","SUSE-SU-2020:3945-1","UBUNTU-CVE-2020-29483","openSUSE-SU-2020:2313-1","openSUSE-SU-2020:2331-1","openSUSE-SU-2024:11520-1"],"status":"published","title":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared...","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","severity":{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H","level":"medium","assessor":"primary","from":"nvd"},"epss":{"day":"2026-11-11","score":0.00375,"percentile":0.3188,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-416"],"published":"2020-12-15T00:00:00Z","modified":"2026-10-26T12:02:48Z","fixes":[{"ecosystem":"Alpine:v3.11","package":"xen","fixed_in":["4.13.2-r3"],"sources":["osv"]},{"ecosystem":"Alpine:v3.12","package":"xen","fixed_in":["4.13.2-r3"],"sources":["osv"]},{"ecosystem":"Alpine:v3.13","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.14","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.15","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.16","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.17","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.18","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.19","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.20","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.21","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.22","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.23","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.24","package":"xen","fixed_in":["4.14.1-r0"],"sources":["osv"]},{"ecosystem":"Debian:12","package":"xen","fixed_in":["4.14.0+88-g1d1d1f5391-1"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"xen","fixed_in":["4.14.0+88-g1d1d1f5391-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"xen","fixed_in":["4.14.0+88-g1d1d1f5391-1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Alpine:v3.11","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.13.2-r3"}]}]},{"source":"osv","ecosystem":"Alpine:v3.12","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.13.2-r3"}]}]},{"source":"osv","ecosystem":"Alpine:v3.13","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.14","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.15","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.16","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.17","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.18","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.19","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.20","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.21","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.22","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.23","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.1-r0"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.0+88-g1d1d1f5391-1"}]}]},{"source":"osv","ecosystem":"Debian:13","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.0+88-g1d1d1f5391-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.14.0+88-g1d1d1f5391-1"}]}]},{"source":"osv","ecosystem":"Debian:10","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.4+57-g41a822c392-2"}]}],"versions":["4.11.1+92-g6c33308a8d-2","4.11.3+24-g14b62ab3e5-1","4.11.3+24-g14b62ab3e5-1~deb10u1","4.11.4+24-gddaaccbbab-1","4.11.4+24-gddaaccbbab-1~deb10u1","4.11.4+37-g3263f257ca-1","4.11.4+57-g41a822c392-1","4.11.4-1"],"bundled":11},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 11 SP4-LTSS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.4.4_48-61.61.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Software Development Kit 12 SP5","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.4_06-3.36.1"}]}],"bundled":9},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP5","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.4_06-3.36.1"}]}],"bundled":9},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 12 SP5","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.4_06-3.36.1"}]}],"bundled":9},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP1","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.4_06-3.40.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP1","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.4_06-3.40.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:OpenStack Cloud 7","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.7.6_14-43.73.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 12 SP2","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.7.6_14-43.73.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP2-LTSS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.7.6_14-43.73.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP2-BCL","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.7.6_14-43.73.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:OpenStack Cloud 9","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.4_16-2.48.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:OpenStack Cloud Crowbar 9","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.4_16-2.48.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 12 SP4","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.4_16-2.48.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP4-LTSS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.11.4_16-2.48.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP2","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.13.2_06-3.22.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP2","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.13.2_06-3.22.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15-ESPOS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.10.4_24-3.53.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15-LTSS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.10.4_24-3.53.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.10.4_24-3.53.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:HPE Helion OpenStack 8","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_16-3.80.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:OpenStack Cloud 8","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_16-3.80.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:OpenStack Cloud Crowbar 8","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_16-3.80.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 12 SP3","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_16-3.80.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP3-LTSS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_16-3.80.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP3-BCL","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_16-3.80.1"}]}],"bundled":8},{"source":"osv","ecosystem":"SUSE:Enterprise Storage 5","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.9.4_16-3.80.1"}]}],"bundled":8},{"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"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.9.2-0ubuntu2","4.9.2-0ubuntu6","4.9.2-0ubuntu7","4.11.3+24-g14b62ab3e5-1ubuntu1","4.11.3+24-g14b62ab3e5-1ubuntu2","4.11.3+24-g14b62ab3e5-1ubuntu2.2","4.11.3+24-g14b62ab3e5-1ubuntu2.3"]},{"source":"osv","ecosystem":"openSUSE:Leap 15.1","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.12.4_06-lp151.2.36.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.2","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.13.2_06-lp152.2.21.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"xen","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.15.1_01-1.2"}]}],"bundled":93}],"products":[{"vendor":"debian","product":"debian_linux"},{"vendor":"fedoraproject","product":"fedora"},{"vendor":"xen","product":"xen"}],"references":[{"url":"https://xenbits.xenproject.org/xsa/advisory-325.txt","tags":["x_refsource_MISC","x_transferred","Patch","Vendor Advisory","fix"]},{"url":"https://www.debian.org/security/2020/dsa-4812","tags":["vendor-advisory","x_refsource_DEBIAN","x_transferred","Third Party Advisory","advisory"]},{"url":"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI/","tags":["vendor-advisory","x_refsource_FEDORA","x_transferred","web"]},{"url":"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA/","tags":["vendor-advisory","x_refsource_FEDORA","x_transferred","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2020-29483"},{"url":"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA/"},{"url":"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI/"},{"url":"https://github.com/advisories/GHSA-q89m-rx2c-6v2g"},{"url":"https://security.alpinelinux.org/vuln/CVE-2020-29483","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2020-29483","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2020/suse-su-202014578-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1179477","tags":["report"]},{"url":"https://bugzilla.suse.com/1179496","tags":["report"]},{"url":"https://bugzilla.suse.com/1179498","tags":["report"]},{"url":"https://bugzilla.suse.com/1179501","tags":["report"]},{"url":"https://bugzilla.suse.com/1179502","tags":["report"]},{"url":"https://bugzilla.suse.com/1179506","tags":["report"]},{"url":"https://bugzilla.suse.com/1179514","tags":["report"]},{"url":"https://bugzilla.suse.com/1179516","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29130","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29480","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29481","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29483","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29484","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29566","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29570","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29571","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2020/suse-su-20203880-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1027519","tags":["report"]},{"url":"https://bugzilla.suse.com/1163019","tags":["report"]},{"url":"https://bugzilla.suse.com/1176782","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2020-8608","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2020/suse-su-20203881-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2020/suse-su-20203913-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2020/suse-su-20203914-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2020/suse-su-20203915-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2020/suse-su-20203916-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2020/suse-su-20203945-1/","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2020-29483","tags":["report"]},{"url":"https://xenbits.xen.org/xsa/advisory-325.html","tags":["report"]},{"url":"https://xenbits.xen.org/xsa/xsa325-4.14.patch","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2020-29483","tags":["report"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/ORUQM2NUGI7GTGQ4QQYAXYCCBGXOCR55/","tags":["advisory"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/KLZB3TTBVYNCRCZSSEYYBTXS7RCM6NL7/","tags":["advisory"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2007-1320","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2007-1366","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2007-3919","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-10013","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-10024","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-10025","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-7777","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-7908","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-7909","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-8667","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-8669","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-8910","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9377","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9379","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9381","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9382","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9383","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9384","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9385","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9386","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9637","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9921","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9932","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-12135","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-12136","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-12137","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-2615","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-2620","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-5753","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-6505","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-8309","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-9330","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-10471","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-10472","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-10981","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-10982","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-12126","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-12891","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-12892","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-12893","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-15468","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-15469","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-15470","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-18883","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-19961","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-19963","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-19964","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-19965","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-19966","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-19967","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-3639","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-3646","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-3665","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-5244","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-7540","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-7541","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-7542","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-8897","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-17349","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-0543","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-11739","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-11740","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-11742","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-11743","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-15563","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-15565","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-15566","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-15567","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25595","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25596","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25597","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25598","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25599","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25600","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25601","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25602","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25603","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-25604","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-27670","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-27671","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-27672","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-27674","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-28368","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29040","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-29567","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2021-28687","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2020-29483","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","status":"published","published":"2020-12-15T17:15:57Z","modified":"2024-08-04T16:55:09.798Z","updated_at":"2026-11-02T14:35:55.460269Z"}],"euvd":[{"id":"EUVD-2020-21851","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","status":"published","published":"2020-12-15T17:15:57Z","modified":"2024-08-04T16:55:09Z","updated_at":"2026-11-03T03:07:07.919663Z"}],"ghsa":[{"id":"GHSA-q89m-rx2c-6v2g","title":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared...","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","status":"published","published":"2022-05-24T17:36:33Z","modified":"2023-01-29T05:05:03Z","cwes":["CWE-416"],"updated_at":"2026-11-02T14:45:42.123832Z"}],"nvd":[{"id":"CVE-2020-29483","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","status":"published","published":"2020-12-15T18:15:15.287Z","modified":"2026-06-17T03:11:20.243Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H","level":"medium","assessor":"primary"},{"version":"2.0","score":4.9,"vector":"AV:L/AC:L/Au:N/C:N/I:N/A:C","level":"medium","assessor":"primary"}],"cwes":["CWE-416"],"updated_at":"2026-11-02T14:06:27.73474Z"}],"osv":[{"id":"ALPINE-CVE-2020-29483","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","status":"published","published":"2020-12-15T18:15:15.287Z","modified":"2026-10-26T11:17:55.168765031Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:27:48.11886Z"},{"id":"CVE-2020-29483","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","status":"published","published":"2020-12-15T18:15:15.287Z","modified":"2026-03-15T22:35:49.192696Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:44:16.612899Z"},{"id":"DEBIAN-CVE-2020-29483","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","status":"published","published":"2020-12-15T18:15:15.287Z","modified":"2026-10-26T12:02:48.353833129Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:45:34.019707Z"},{"id":"UBUNTU-CVE-2020-29483","description":"An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.","status":"published","published":"2020-12-15T18:15:00Z","modified":"2026-04-22T12:39:34.25048Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:54:24.541803Z"},{"id":"DSA-4812-1","title":"xen - security update","status":"published","published":"2020-12-15T00:00:00Z","modified":"2026-03-09T02:11:08.819507Z","updated_at":"2026-11-02T15:46:17.19998Z"},{"id":"openSUSE-SU-2020:2313-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n\nThis update was imported from the SUSE:SLE-15-SP1:Update update project.","status":"published","published":"2020-12-22T05:22:46Z","modified":"2025-05-07T18:12:04.496935Z","updated_at":"2026-11-02T16:58:31.517538Z"},{"id":"openSUSE-SU-2020:2331-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n\nThis update was imported from the SUSE:SLE-15-SP2:Update update project.","status":"published","published":"2020-12-26T05:22:25Z","modified":"2026-02-04T03:38:08.826583Z","updated_at":"2026-11-02T16:58:31.879684Z"},{"id":"openSUSE-SU-2024:11520-1","title":"xen-4.15.1_01-1.2 on GA media","description":"These are all security issues fixed in the xen-4.15.1_01-1.2 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-06-15T00:00:00Z","modified":"2025-05-07T18:08:22.378535Z","updated_at":"2026-11-02T16:58:35.195147Z"},{"id":"SUSE-SU-2020:14578-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- CVE-2020-29130: Fixed an out-of-bounds access while processing ARP packets (bsc#1179477). \n","status":"published","published":"2020-12-16T16:52:35Z","modified":"2026-02-04T03:40:59.864471Z","updated_at":"2026-11-02T15:53:47.634847Z"},{"id":"SUSE-SU-2020:3880-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- CVE-2020-29130: Fixed an out-of-bounds access while processing ARP packets (bsc#1179477). \n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n","status":"published","published":"2020-12-18T15:47:02Z","modified":"2026-02-04T04:36:31.987762Z","updated_at":"2026-11-02T15:53:48.690034Z"},{"id":"SUSE-SU-2020:3881-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n","status":"published","published":"2020-12-18T15:47:14Z","modified":"2026-02-04T03:39:37.252654Z","updated_at":"2026-11-02T15:53:48.690034Z"},{"id":"SUSE-SU-2020:3913-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- CVE-2020-29130: Fixed an out-of-bounds access while processing ARP packets (bsc#1179477). \n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n","status":"published","published":"2020-12-22T13:16:01Z","modified":"2026-02-04T03:59:34.976076Z","updated_at":"2026-11-02T15:53:48.690034Z"},{"id":"SUSE-SU-2020:3914-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- CVE-2020-29130: Fixed an out-of-bounds access while processing ARP packets (bsc#1179477). \n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n","status":"published","published":"2020-12-22T13:16:20Z","modified":"2026-02-04T02:25:51.054779Z","updated_at":"2026-11-02T15:53:48.690034Z"},{"id":"SUSE-SU-2020:3915-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n","status":"published","published":"2020-12-22T13:16:30Z","modified":"2026-02-04T02:49:46.962806Z","updated_at":"2026-11-02T15:53:48.690034Z"},{"id":"SUSE-SU-2020:3916-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n","status":"published","published":"2020-12-22T13:16:42Z","modified":"2026-02-04T03:24:53.042108Z","updated_at":"2026-11-02T15:53:48.690034Z"},{"id":"SUSE-SU-2020:3945-1","title":"Security update for xen","description":"This update for xen fixes the following issues:\n\n- CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).\n- CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322). \n- CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).\n- CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324). \n- CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).\n- CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).\n- CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).\n- CVE-2020-29130: Fixed an out-of-bounds access while processing ARP packets (bsc#1179477). \n- Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).\n- Multiple other bugs (bsc#1027519)\n","status":"published","published":"2020-12-29T12:09:29Z","modified":"2026-02-04T02:51:22.921364Z","updated_at":"2026-11-02T15:53:48.690034Z"}]}}