New security updates are available for the only currently supported release of XCP-ng: 8.2 LTS.
Several vulnerabilities have been discovered and fixed in Xenstored, a component of the Xen hypervisor which allows the host and guest to exchange information.
They may let a privileged user in a guest VM make a portion of the management service non-responsive, preventing the creation of new guests or not allowing the configuration of running guests to be changed.
Among the fixed vulnerabilities, some do not affect XCP-ng in its default configuration, where the OCaml version of
xenstored is used (
oxenstored), but they will affect it if you changed the settings to make XCP-ng use the C version of
To address the vulnerabilities, we release updates for these components in XCP-ng.
🔒 Fixed vulnerabilities
We split the fixed vulnerabilities in two categories: those affecting the default XCP-ng configuration, and also those for people who chose to rely on the C implementation of Xenstored, which isn't enabled by default.
Vulnerabilities in the default configuration
There are two Xen Security Advisories (XSAs) affecting XCP-ng, with the default configuration.
- "Unprivileged guests can cause a DoS of xenstored, resulting in the inability to create new guests or modify the configuration of running guests."
- Reference: https://xenbits.xen.org/xsa/advisory-326.html
- "Since the fix of XSA-322, [...] two malicious guests working together can drive xenstored into an out of memory situation, resulting in a Denial of Service (DoS) of xenstored. This inhibits creation of new guests and changing the configuration of already running guests."
- Reference: https://xenbits.xen.org/xsa/advisory-419.html
Vulnerabilities in the C version of Xenstored
This time, those XSA are only affecting the C version, not used by default in XCP-ng. However, we are bundling them in case some users rely on it. Better safe than sorry.
- "Due to a bug in the fix of XSA-115 [...] a malicious guest cause xenstored to crash, resulting in the inability to create new guests or to change the configuration of running guests."
- Reference: https://xenbits.xen.org/xsa/advisory-414.html
- "By creating multiple nodes inside a transaction resulting in an error, [...] a malicious guest can cause inconsistencies in the xenstored data base, resulting in unusual error responses or memory leaks in xenstored. This can finally cause Denial of Service situations or long running error recoveries of xenstored."
- Reference: https://xenbits.xen.org/xsa/advisory-415.html
- "A malicious guest can cause DoS of xenstored, resulting in the inability to create new guests or to change the configuration of already running guests."
- Reference: https://xenbits.xen.org/xsa/advisory-416.html
- "In some circumstances, it might be possible for a new guest domain to access resources belonging to a previous domain. The impact would depend on the software in use and the configuration, but might include any of denial of service, information leak, or privilege escalation."
- Reference: https://xenbits.xen.org/xsa/advisory-417.html
- "A malicious guest creating very deep nesting levels of Xenstore nodes might be able to crash xenstored, resulting in a Denial of Service (DoS) of Xenstore. This will inhibit creation of new guests or changing the configuration of already running guests."
- Reference: https://xenbits.xen.org/xsa/advisory-418.html
- "In case a node has been created in a transaction and it is later deleted in the same transaction, the transaction will be terminated with an error. As this error is encountered only when handling the deleted node at transaction finalization, the transaction will have been performed partially and without updating the accounting information. This will enable a malicious guest to create arbitrary number of nodes."
- Reference: https://xenbits.xen.org/xsa/advisory-421.html