CVE-2020-29483 json
An issue was discovered in Xen through 4.14.x.
published 5y ago modified 4mo ago also EUVD-2020-21851
- cvss
- 6.5
- version 3.1, NVD
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.4%
- EPSS 0.4% chance of exploitation in 30 days, percentile 31%
- public exploits
- 0
- none known
Summary
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.
Patch / fix
- xen Debian 14, Debian 13, Debian 12 4.14.0+88-g1d1d1f5391-1
debian advisories DEBIAN-CVE-2020-29483
- xen SLES for SAP 12 SP3, SLES 12 SP3-LTSS, SLES 12 SP3-BCL +4 more 4.9.4_16-3.80.1
- xen SLES for SAP 15, SLE High Performance Computing 15-LTSS, SLE High Performance Computing 15-ESPOS 4.10.4_24-3.53.1
- xen SLE Module for Server Applications 15 SP2, SLE Module for Basesystem 15 SP2 4.13.2_06-3.22.1
- xen SLES for SAP 12 SP4, SLES 12 SP4-LTSS, OpenStack Cloud Crowbar 9 +1 more 4.11.4_16-2.48.1
- xen SLES for SAP 12 SP2, SLES 12 SP2-LTSS, SLES 12 SP2-BCL +1 more 4.7.6_14-43.73.1
- xen SLE Module for Server Applications 15 SP1, SLE Module for Basesystem 15 SP1 4.12.4_06-3.40.1
- xen SLES for SAP 12 SP5, SLES 12 SP5, SLE Software Development Kit 12 SP5 4.12.4_06-3.36.1
- xen SLES 11 SP4-LTSS 4.4.4_48-61.61.1
suse advisories SUSE-SU-2020:3945-1SUSE-SU-2020:3916-1SUSE-SU-2020:3915-1SUSE-SU-2020:3914-1SUSE-SU-2020:3913-1SUSE-SU-2020:3881-1
- xen openSUSE Tumbleweed 4.15.1_01-1.2
- xen openSUSE Leap 15.2 4.13.2_06-lp152.2.21.1
- xen openSUSE Leap 15.1 4.12.4_06-lp151.2.36.1
opensuse advisories openSUSE-SU-2024:11520-1openSUSE-SU-2020:2331-1openSUSE-SU-2020:2313-1
- xen Alpine 3.12, Alpine 3.11 4.13.2-r3
- xen Alpine 3.24, Alpine 3.23, Alpine 3.22 +9 more 4.14.1-r0
alpine advisories ALPINE-CVE-2020-29483
Alpine secdb © Alpine Linux, from https://secdb.alpinelinux.org via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
Is CVE-2020-29483 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerVendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2020-29483 updated cvss 6.2
xen: Xenstore: guests can disturb domain cleanup (XSA-325)
-
Red Hat All currently supported Red Hat productsnot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.38% chance of exploitation in the next 30 days, higher than 31% of all scored CVEs (FIRST EPSS, 2026-11-09).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| NVD | 3.1 | 6.5 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H |
| NVD | 2.0 | 4.9 | AV:L/AC:L/Au:N/C:N/I:N/A:C |
Classification
- Weakness
-
- CWE-416 Use After Free
References
-
xenbits.xenproject.org
/xsa/advisory-325.txt
patch, vendor-advisory
-
debian.org
/security/2020/dsa-4812
vendor-advisory, third-party-advisory
-
lists.fedoraproject.org
/archives/list/package-announce%40lists.fedoraproject.org/message/OBLV6L6Q24PPQ2CRFXDX4Q76KU776GKI/
vendor-advisory
-
lists.fedoraproject.org
/archives/list/package-announce%40lists.fedoraproject.org/message/2C6M6S3CIMEBACH6O7V4H2VDANMO6TVA/
vendor-advisory
Sources
- CVE List CVE-2020-29483
- NVD CVE-2020-29483
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.