[Xen-devel] Xen Security Advisory 279 v2 - x86: DoS from attempting to use INVPCID with a non-canonical addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-279 version 2 x86: DoS from attempting to use INVPCID with a non-canonical addresses UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The INVPCID instruction raises #GP[0] if an attempt is made to invalidate a non-canonical address. Older flushing mechanisms such as INVLPG tolerate this without error, and perform no action. There is one guest accessible path in Xen where a non-canonical address was passed into the TLB flushing code. This previously had no ill effect, but became vulnerable with the introduction of PCID to reduce the performance hit from the Meltdown mitigations. IMPACT == A buggy or malicious PV guest can crash the host. VULNERABLE SYSTEMS == Only hardware which supports the INVPCID instruction is vulnerable. This is available on Intel Haswell processors and later. AMD x86 processors are not known to support this instruction, and ARM processors are entirely unaffected. Only versions of Xen with PCID support are vulnerable. Support first appeared in Xen 4.11 but was backported to the stable trees as part of the Meltdown (XSA-254 / CVE-2017-5754) fixes. Xen 4.10.2, 4.9.3, 4.8.4 as well as the stable-4.7 and 4.6 branches are vulnerable. The vulnerability is only exposed to 64-bit PV guests. 32-bit PV guests, as well as HVM/PVH guests cannot exploit the vulnerability. MITIGATION == Booting Xen with `pcid=0` or `invpcid=0` on the command line will work around the issue. Alternatively, running untrusted 64bit PV guests inside xen-shim will work around the issue. CREDITS === This issue was discovered by Matthew Daley. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa279.patch xen-unstable, Xen 4.11.x, Xen 4.10.x xsa279-4.9.patch Xen 4.9.x ... 4.7.x $ sha256sum xsa279* 40319fcf33348176eb14d7fc7c68c255cc7291013242ea444de6d00602024a11 xsa279.meta 0c1d50effe6645051a15dd83af57088dd4a055e26a23b1fa9e6c3722a7973f5d xsa279.patch fd34f29bc7e53359585135408cbbd12e12a003f59b135e81cc44186c5cddd40d xsa279-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlv0C2oMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZKtwH/iNT0SP+by+n+HfWJfl4hZgJ4ZU3ZJDXyxuMchHv ZXYxW9FEab34qjOtRKToIYaPybjULbCNf2EeSmdwuHS55BP+GlnGT27gCU0FSECJ bfCkXFAJh04SjjzInOQxyfMUPmCztnwQvzADPJkxp1+nc++9P66Y44AwzUrRHsT1 A/dryLbZP/WiFyfYBnBPeh8Ib2eaAA1cxWLVbHwYlrrzgwf8pLHtKObW1TiSS/gr inPqwvcU3dwj3OnsB2KuWodgP7cN/YyE/pdCiSiR7xZqcWN5/bdodwARhGTc2XY3 2OLodVSz962xjmCku7YN0ntiuU1C/c7w2dT5KsF9H/mPwl4= =f39b -END PGP SIGNATURE- xsa279.meta Description: Binary data xsa279.patch Description: Binary data xsa279-4.9.patch Description: Binary data _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 280 v2 - Fix for XSA-240 conflicts with shadow paging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-280 version 2 Fix for XSA-240 conflicts with shadow paging UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The fix for XSA-240 introduced a new field into the control structure associated with each page of RAM. This field was added to a union, another member of which is used when Xen uses shadow paging for the guest. During migration, or with the L1TF (XSA-273) mitigation for PV guests in effect, the two uses conflict. IMPACT == A malicious or buggy x86 PV guest may cause Xen to crash, resulting in a DoS (Denial of Service) affecting the entire host. Privilege escalation as well as information leaks cannot be ruled out. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only x86 systems are affected. ARM systems are not affected. Only Xen versions with the XSA-240 fixes applied are vulnerable. Only Xen versions which permit linear page table use by PV guests are vulnerable. Only x86 PV guests can leverage this vulnerability. x86 HVM guests cannot leverage this vulnerability. MITIGATION == Not permitting linear page table use by PV guests avoids the vulnerability. This can be done both at build time, by turning off the PV_LINEAR_PT configure option, or at runtime, by passing specifying "pv-linear-pt=0" on the hypervisor command line. On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which have themselves been hardened against L1TF _and_ avoiding live migrating or snapshotting PV guests will generally prevent this issue being triggered. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. Running only HVM guests will avoid this vulnerability. CREDITS === This issue was discovered by the security team of Prgmr.com. RESOLUTION == Applying the appropriate pair of attached patches resolves this issue. xsa280-?.patch xen-unstable xsa280-1.patch + xsa280-4.11-2.patch Xen 4.11.x xsa280-1.patch + xsa280-4.10-2.patch Xen 4.10.x xsa280-4.9-1.patch + xsa280-4.10-2.patch Xen 4.9.x, Xen 4.8.x xsa280-4.9-1.patch + xsa280-4.7-2.patch Xen 4.7.x $ sha256sum xsa280* ff0b376b9e2ec16f7c15b144d4d38375d6f6b4019aa9c17f6b80f9dfe40319ef xsa280.meta 41b2b91dbabbf2048c790c5934ab696ef53932ff98d1069eb7c7ae52e61cd44b xsa280-1.patch d46e46a6e706e0d3416d40ed12227223f7e8f825dfc63ed203c1df115976e8a1 xsa280-2.patch 163eaf2e16d5cc314a81fa1254eb2809674001b2329c41556a078b7f94e72ced xsa280-4.7-2.patch 22e9d29f316356341db40c743ca59f9bb9d783a58fb6429d5badf57a77b5f34a xsa280-4.9-1.patch ff0a839dbd9347ec88aaeb7ef1145d0cd9029a19c6a478088c63c0959ba0e740 xsa280-4.10-2.patch 87940f3b84d0adfd89e1b2bc1a872ae2948e1621e4994e7879b77e327b0136b5 xsa280-4.11-2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) EXCEPT the linear page table disabling one is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However deployment of the linear page table disabling mitigation is NOT PERMITTED (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because altering the set of features usable in a guest in connection with a security issue would be a user-visible change which could lead to the rediscovery of the vulnerability. Also: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlv0DEsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZnkQH/iyCga79/YRwqCHB5nrTlQhY0g6E5zA2debKtfxS MPosJQZy7/PzkvbBPnHBYEve8UyvQuVQXs+WOhCL7625
[Xen-devel] Xen Security Advisory 254 - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-254 Information leak via side effects of speculative execution ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): SP1, "Bounds-check bypass": Poison the branch predictor, such that operating system or hypervisor code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. SP2, "Branch Target Injection": Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that exists in the hypervisor. SP3, "Rogue Data Load": On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ Additional Xen-specific background: 64-bit Xen hypervisors on systems with less than 5TiB of RAM map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (HVM and PVH guests run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, or SP2 on systems where SMEP (supervisor mode execute protection) is enabled: an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2 without SMEP, or SP3, an attacker can write arbitrary code to speculatively execute. NOTE ON TIMING == This vulnerability was originally scheduled to be made public on 9 January. It was accelerated at the request of the discloser due to one of the issues being made public. VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. For SP1 and SP2, both Intel and AMD are vulnerable. For SP3, only Intel processors are vulnerable. Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH and 32-bit PV guests cannot exploit SP3. We believe that ARM is affected, but unfortunately due to the accelerated schedule, we haven't been able to get concrete input from ARM. We are asking ARM and will publish more information when it is available. MITIGATION == There is no mitigation for SP1 and SP2. SP3 can be mitigated by running guests in HVM or PVH mode. For guests with legacy PV kernels which cannot be run in HVM mode, we have developed a "shim" hypervisor that allows PV guests to run in PVH mode. Unfortu
[Xen-devel] Xen Security Advisory 253 - x86: memory leak with MSR emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-253 version 2 x86: memory leak with MSR emulation UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = In Xen 4.10, new infrastructure was introduced as part of an overhaul to how MSR emulation happens for guests. Unfortunately, one tracking structure isn't freed when a vcpu is destroyed. IMPACT == A memory allocation of 8 bytes is leaked each time a vcpu is destroyed. A malicious guest may, by frequently rebooting over extended periods of time, run the system out of memory, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS ====== Xen versions 4.10 and later are affected. Xen 4.9 and earlier are not affected. Only x86 systems are affected. ARM systems are not. All guest kinds can exploit this vulnerability. MITIGATION == Limiting the frequency with which a guest is able to reboot, will limit the memory leak. Rebooting each host (after migrating its guests) periodically will reclaim the leaked space. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa253.patch Xen 4.10, xen-unstable $ sha256sum xsa253* bba1abb5e4368421de29385e37f8477bf3534d3ba3ff7e2aae9c9d3da53f1393 xsa253.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJaTiXyAAoJEIP+FMlX6CvZ/CIH/3LEbyAmWUSs4C2Rt0EENDLO JnnAGXWIy3DsffGiG9zOhfYiItn2iD+J+EcO+WC5lGPBSkX1KiXdsWVla/dJuy0F frx5pdqJNSHFihK/6fGU0WnSBFz6o2gkn2hOnzWfpxNLiJMrHCI6GEOcdMx6xtOQ 9QZAa7rCN1aRx0Lx1LjuvaqPwy4rJ294zLnwarMoN10KZ3oRVbQ8mf4kN+/X+hlK 9MxUj99WYZWcJhcRLGiQALPdRQeabh72/ZTFsfIAwPxaEgT6YhwFrFDG526iNcM0 MkruO8HeD+byrQrni/qgB5EAIyPsFuBfvzddHzPA+9sSrf4QDjQWPFihQ3ti+xg= =sQVC -END PGP SIGNATURE- xsa253.patch Description: Binary data _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 3 Information leak via side effects of speculative execution UPDATES IN VERSION 3 Add information about ARM vulnerability. Correct description of SP2 difficulty. Mention that resolutions for SP1 and SP3 may be available in the future. Move description of the PV-in-PVH shim from Mitigation to Resolution. (When available and deployed, it will eliminate the SP3 vulnerability.) Add colloquial names and CVEs to the relevant paragraphs in Issue Description. Add a URL. Say explicitly in Vulnerable Systems that HVM guests cannot exploit SP3. Clarify that SP1 and SP2 can be exploited against other victims besides operating systems and hypervisors. Grammar fixes. Remove erroneous detail about when Xen direct maps the whole of physical memory. State in Description that Xen ARM guests run in a separate address space. ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing
[Xen-devel] Xen Security Advisory 253 (CVE-2018-5244) - x86: memory leak with MSR emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-5244 / XSA-253 version 3 x86: memory leak with MSR emulation UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = In Xen 4.10, new infrastructure was introduced as part of an overhaul to how MSR emulation happens for guests. Unfortunately, one tracking structure isn't freed when a vcpu is destroyed. IMPACT == A memory allocation of 8 bytes is leaked each time a vcpu is destroyed. A malicious guest may, by frequently rebooting over extended periods of time, run the system out of memory, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS ====== Xen versions 4.10 and later are affected. Xen 4.9 and earlier are not affected. Only x86 systems are affected. ARM systems are not. All guest kinds can exploit this vulnerability. MITIGATION == Limiting the frequency with which a guest is able to reboot, will limit the memory leak. Rebooting each host (after migrating its guests) periodically will reclaim the leaked space. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa253.patch Xen 4.10, xen-unstable $ sha256sum xsa253* bba1abb5e4368421de29385e37f8477bf3534d3ba3ff7e2aae9c9d3da53f1393 xsa253.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJaUOoXAAoJEIP+FMlX6CvZchUIAKlvxu5o9IcIyULARW0s2YEA 6ueK3tyaH2vlWH1IG9KORletdAGALJrfEODt8SBJb+0rKDZKGHSKNB7a911QRebK njXdSpdb1WCdHmStI82csLKvdMGbrFq/6wWFJRt1eFtzr7Qt3rwKXtHv/OI4Kr1T sZ+K6M2KCavkJ+yPSF/f9GTBuD6iiu2E7RI5HzbjdV+k9E7tJkURH2/BPAfhhhyo zsColbPQAxm96RCHIEPaOI5qZXVcfL+5VNbUh5+6vOtUiZdpnOMHmSwDF0AZc1hO 0YQ93/8blRm7N914rn8gu0zY+nQHcgC2klWzHOcCFirzTI0aHXfQQJsX9Oe6g3w= =CX95 -END PGP SIGNATURE- xsa253.patch Description: Binary data _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 251 (CVE-2017-17565) - improper bug check in x86 log-dirty handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-17565 / XSA-251 version 3 improper bug check in x86 log-dirty handling UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Memory sharing, available to x86 HVM guests only, uses a special value in the global machine to physical address translation table (M2P). PV guests have full control over M2P entries corresponding to pages they own. A bug check (specifically, an assertion that an M2P entry is not the special "shared" indicator) was insufficiently qualified, and as a consequence is triggerable by PV guests in log-dirty mode (e.g. because of being live migrated). IMPACT == A malicious or buggy PV guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS ====== Xen versions 4.0 and later are affected. Xen versions 3.4 and earlier are not affected. Only x86 systems are vulnerable. ARM systems are not vulnerable. x86 HVM guests cannot exploit this vulnerability. Only x86 PV guests can exploit this vulnerability, and only when being run in shadow mode. PV guests are typically run in shadow mode for live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). MITIGATION == Running only HVM guests avoids the vulnerability. Avoiding live migration of x86 PV guests also avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa251.patch xen-unstable, Xen 4.9.x xsa251-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa251-4.5.patch Xen 4.5.x $ sha256sum xsa251* 152cf5c88c3e441af01cdf5749877cabb6ab961afee9f29ae3077e725b703aa2 xsa251.meta 0dfbcfe459f051abb571d3fbedbe9760a4c6cd540ab5d525627050e3eeb9234e xsa251.patch 345a6e004e0d0d89c7fc8db55d48d68f53402a521bd1aa3cb4168043e1ae5673 xsa251-4.5.patch f8cecf013a3628038e0a4566778852a560b25a1ce2f3872a989087ab2fc9a913 xsa251-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJaUPXgAAoJEIP+FMlX6CvZd1wIALEfYx5UtaqCZrUpgc+TwN8u Fg+huu3hE/YDVMY5IHueUsVU4WMk7/XJL/hXxf0+Dr01M5nVUbs1cJIB7Gqch37n Vo6JMHM0XHUEQB/Ctxn/nRi1PfAjvz/nSrCcRacIeTZNHm6Wzc7qtlOyjDWgbVwJ JvboCmK0ueGTVd3RIGvxM0jDzWqRuObf4KLaCWka3rqZvYzZJJOGAO9C8HdZn9Bc pMIV79QuYySvJm9rdNUSno2s19DJNNCOki2/HpU1CHv/b8May82fE+qZH5XexsnZ x2d1G8cvsK0L+auqQO/U3Rln9B2MWp9hn2cVGP2DbLq/AO2yir5b7d/CPzqhIag= =O0vJ -END PGP SIGNATURE- xsa251.meta Description: Binary data xsa251.patch Description: Binary data xsa251-4.5.patch Description: Binary data xsa251-4.8.patch Description: Binary data ___________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 248 (CVE-2017-17566) - x86 PV guests may gain access to internally used pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-17566 / XSA-248 version 3 x86 PV guests may gain access to internally used pages UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Memory management for PV guests builds on page ownership and page attributes. A domain can always map, at least r/o, pages of which it is the owner. Certain fields in the control structure of a page are used for different purposes in the main PV memory management code and in code handling shadow paging. When a guest is running in shadow mode (which for PV guests is necessary e.g. for live migration), certain auxiliary pages used by Xen internally had their owner set to the guest itself. When the PV guest maps such a page, shadow code and PV memory management code will disagree on the meaning of said multi-purpose fields, generally leading to a crash of the hypervisor. IMPACT == A malicious or buggy PV guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. x86 HVM guests cannot exploit this vulnerability. Only x86 PV guests can exploit this vulnerability, and only when being run in shadow mode. PV guests are typically run in shadow mode for live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). MITIGATION == Running only HVM guests avoids the vulnerability. Avoiding live migration of x86 PV guests also avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa248.patch xen-unstable, Xen 4.9.x xsa248-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa248-4.5.patch Xen 4.5.x $ sha256sum xsa248* f0ac5c5ff956118f52821e111c6e27416f788cea6e98cc54cb051c42b793357e xsa248.meta 20bcfb1890d90bd74f52e45a1e8aa020a8991e3a0db37eecf53ce48b16e602bf xsa248.patch ec4227633df18f76fbd8cb12e367879470b63fb5236f10b2a971dccef9f83172 xsa248-4.5.patch 3bbd9fd92e5ffab1ddd7ff804bfbab09c1c654af3aa7f80f742f321da120b715 xsa248-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJaUPXWAAoJEIP+FMlX6CvZ5R8H/Rn0CZ9fEExfAjcqm5kjTZFt HgI+ZfUYwhEfMuYc4bv5rYYfzhFsCWe4afrcxBdh1qtMeJjZWfGtf8yOFNzox0PR XeMZ/p7qwspg9TyNO/7dM+wd6nHRp88pTcy4QQcmfczcZrcUbm0wGCmhaIJdWlMA CsgKsiekPapB9R+fqeVroc/gmMRx9iTFif/w96OpApGsMPO5SnuSzeFrL8RzMU9u rjwCfu0Yz9MPHT8E+KvI9GeB7srov3XEfMsmaJ9NUDgnrDl9Xhe5wC7FnL3mvTYC YZML85QbvghxFoQM6v2MyBwF8tLW3YEgZK/oR4ed1E6BrKfDQwyXIaT0GXtIFzk= =ytqY -END PGP SIGNATURE- xsa248.meta Description: Binary data xsa248.patch Description: Binary data xsa248-4.5.patch Description: Binary data xsa248-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 250 (CVE-2017-17564) - improper x86 shadow mode refcount error handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-17564 / XSA-250 version 3 improper x86 shadow mode refcount error handling UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Pages being used to run x86 guests in shadow mode are reference counted to track their uses. When another reference cannot be acquired, the corresponding page table entry must not be inserted. Due to incorrect error handling, this constraint could be violated. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == All Xen versions are affected. x86 systems are vulnerable. ARM systems are not vulnerable. Only guests run in shadow mode can exploit the vulnerability. PV guests typically only run in shadow mode during live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). HVM guests run in shadow mode on hardware without HAP support, or when HAP is disabled (globally or in the VM configuration file). Live migration does not affect an HVM guest's use of shadow mode. MITIGATION == For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. For PV guests, avoiding their live migration avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa250.patch xen-unstable, Xen 4.9.x ... 4.6.x xsa250-4.5.patch Xen 4.5.x $ sha256sum xsa250* c15c1c3e64cfb7ab2e2c48970214aa8c3881deb7e11c498526554bb74535b601 xsa250.meta adf4d8242dbddb4ec52fe1effc1f8b233d33d8d6a59c1bb677dcc6e2ed2bf711 xsa250.patch d123a58308db606185c4e48dcf4a114ac29bb988ffc0eeb04ded213ec474e0f2 xsa250-4.5.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJaUPXdAAoJEIP+FMlX6CvZeoMH/iS1gZ8zBPWnBCSPm4pUt9ZJ cAJ9vX9E3wDZm0hEQRHOFvTlpqEY3w5TkkBZbErB8m1VD/Om45fZiHvvZRKPtCvK Jks8OVH2Mx2466WladCK4x3km86N2o2547u03dZzZIDUCvn19S8acI1wV8r4TOrv Op4VeDH+cxJ2EAmmrGWkCJc4lQxvJTqzsz+paZ+/dyOdaZGIKJJOhX6s7ZmkjhZz HHr05i+U72kzttUIYqVO4CIp3hoPsOyAcHsd004XGGH6LmWUA7bG1+Fcm+7b2ajD JX/l4xVstD8GWijRnyvOVo/ozRAGb+Nfve+xtVzbyozqVol5PTcP6Jwxerby8PA= =tkcf -END PGP SIGNATURE- xsa250.meta Description: Binary data xsa250.patch Description: Binary data xsa250-4.5.patch Description: Binary data _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 249 (CVE-2017-17563) - broken x86 shadow mode refcount overflow check
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-17563 / XSA-249 version 3 broken x86 shadow mode refcount overflow check UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Pages being used to run x86 guests in shadow mode are reference counted to track their uses. Unfortunately the overflow check when trying to obtain a new reference used a mask one bit wider than the reference count actually is, rendering the entire check ineffective. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == Xen versions 4.1 and later are affected. Xen versions 4.0 and earlier are not affected. x86 systems are vulnerable. ARM systems are not vulnerable. Only guests run in shadow mode can exploit the vulnerability. PV guests typically only run in shadow mode during live migration, as well as for features like VM snapshot. Note that save / restore does *not* use shadow mode, and so does not expose this vulnerability. Some downstreams also include a "non-live migration" feature, which also does not use shadow mode (and thus does not expose this vulnerability). HVM guests run in shadow mode on hardware without HAP support, or when HAP is disabled (globally or in the VM configuration file). Live migration does not affect an HVM guest's use of shadow mode. MITIGATION == For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. For PV guests, avoiding their live migration avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch resolves this issue. xsa249.patch xen-unstable, Xen 4.9.x ... 4.5.x $ sha256sum xsa249* 38a4b8033d634e22939ad42b882c35e46482782619e3e03b968a2f6489e459c9 xsa249.meta e99066b0171d4757c6a66e1223aabe01e990de2d0dc50416936e064e6e750d00 xsa249.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJaUPXbAAoJEIP+FMlX6CvZdqQH/2b6yXlcScNp9SWs2VIoDLcc Hh3Wxmvx4oRBkdUOiE7/YNJK3yScnW2Jled+fLrBd7yuFNmztlA6Hue1thxgQmFN N2qDReHVBhLDQSv4Xolyifqx/leMo/s7jYkL8zBEPvRrf4DMkj7+i9/JBn8gri8G hiImDmIet9pKL9OP+jQDsgQia5p7ygPVLommMVS/2VZp4O4sBnpvfrAIHNvmmLPy xbr3Jw8cska7gspfmsXU1PziBFmawxk21pvozef9XN1lxC/ZY56yODtph/6KoBvr KGtGleF0QVtj/Nvt42yBr5nMagl9XsjdFz4Jero0K4hOE1Kw7IgO0Oigav8nap8= =Z+E8 -END PGP SIGNATURE- xsa249.meta Description: Binary data xsa249.patch Description: Binary data _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 4 Information leak via side effects of speculative execution UPDATES IN VERSION 4 Added README for determining which shim to use, as well as instructions for using "Vixen" (HVM shim) and the required conversion script ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system provider for more information. NOTE ON TIMING == This vulnerability was originally scheduled to be made public on 9 January. It was accelerated at the request of the discloser due to one of the issues being made public. VULNERABLE SYSTEMS == Systems running all versions of
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 5 Information leak via side effects of speculative execution UPDATES IN VERSION 5 PV-in-PVH/HVM shim approach leaves *guest* vulnerable to Meltdown attacks from its unprivileged users, even if the guest has KPTI patches. That is, guest userspace can use Meltdown to read all memory in the same guest. In Vixen shim sidecar creator script, look for qemu in some more places, and provide a command line option to specify the qemu-system-i386 to use in case the default doesn't find it. ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system provider for more information. NOTE ON T
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 6
Information leak via side effects of speculative execution
UPDATES IN VERSION 6
PVH shim ("Comet") for 4.10 is available.
Mention within-guest attack in README.vixen as well as
README.which-shim.
Vixen shim converter script "exec"s qemu, avoiding stale qemu
processes (and, therefore, avoiding stale domains).
ISSUE DESCRIPTION
=
Processors give the illusion of a sequence of instructions executed
one-by-one. However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel. In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be. If the guess is correct, execution has been sped up. If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all. This is sometimes called "speculative execution".
Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back. These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase. If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.
Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):
"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks. This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.
"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor. Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead. Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).
"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks. On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.
More information is available here:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
Additional Xen-specific background:
Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.
When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level. (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.) However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.
IMPACT
==
Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.
An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers. For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.
Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.
NOTE ON TIMING
==
This vulnerability was originally scheduled to be made public on 9
January. It was accelerated at the request of the discloser due to
one o
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 7
Information leak via side effects of speculative execution
UPDATES IN VERSION 7
PVH shim ("Comet") for 4.10 tag correction: please use tag
4.10.0-shim-comet-1.1.
ISSUE DESCRIPTION
=
Processors give the illusion of a sequence of instructions executed
one-by-one. However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel. In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be. If the guess is correct, execution has been sped up. If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all. This is sometimes called "speculative execution".
Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back. These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase. If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.
Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):
"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks. This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.
"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor. Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead. Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).
"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks. On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.
More information is available here:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
Additional Xen-specific background:
Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.
When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level. (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.) However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.
IMPACT
==
Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.
An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers. For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.
Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware. Consult your
operating system provider for more information.
NOTE ON TIMING
==
This vulnerability was originally scheduled to be made public on 9
January. It was accelerated at the request of the discloser due to
one of the issues being made public.
VULNERABLE SYSTEMS
==
Systems running all versions of Xen are affected.
For SP1 and SP2, both Intel and
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 8
Information leak via side effects of speculative execution
UPDATES IN VERSION 8
PVH shim ("Comet") is now available for Xen 4.8.
Fixes for two bugs in PVH shim "Comet": one relating to shim
initialisation, which can cause hangs during guest boot shortly after
host boot(!), and one to make qemu PV backends work in PVH mode.
Thanks to the respective contributors.
We are longer inclined to port the "Comet" patches to Xen 4.9. If
this causes you a problem please let us know by contacting us:
To: secur...@xenproject.org; CC: xen-devel@lists.xenproject.org
ISSUE DESCRIPTION
=
Processors give the illusion of a sequence of instructions executed
one-by-one. However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel. In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be. If the guess is correct, execution has been sped up. If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all. This is sometimes called "speculative execution".
Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back. These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase. If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.
Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):
"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks. This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.
"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor. Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead. Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).
"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks. On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.
More information is available here:
https://meltdownattack.com/
https://spectreattack.com/
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
Additional Xen-specific background:
Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.
When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level. (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.) However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.
IMPACT
==
Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.
An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers. For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes. For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.
Additionally, in general, attacks within a guest (from guest user to
guest kernel) will b
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 9 Information leak via side effects of speculative execution UPDATES IN VERSION 9 "Stage 1" pagetable isolation (PTI) Meltdown fixes for Xen are available. "Comet" updates to shim code (4.10 branch): * Include >32vcpu workaround in shim branch so that all shim guests can boot without hypervisor changes. * Fix shim build on systems whose find(1) lacks -printf * Place shim trampoline at page 0x1 to avoid having 0 mapped (4.8 "Comet" users are using the 4.10 shim and may want to update.) ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system prov
[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 10 Information leak via side effects of speculative execution UPDATES IN VERSION 10 = Provided summary table for the varous Meltdown options. Note that in XSA-254 v9's Updates section we said * Include >32vcpu workaround in shim branch ... but this workaround is for guests with 32 or *fewer* vcpus; guests with more will still need the L0 hypervisor patched and rebooted. ISSUE DESCRIPTION = Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called "speculative execution". Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained. Furthermore, these guesses can often be 'poisoned', such that attacker can cause logic to reliably 'guess' the way the attacker chooses. This advisory discusses three ways to cause speculative execution to access sensitive memory areas (named here according to the discoverer's naming scheme): "Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753): Poison the branch predictor, such that victim code is speculatively executed past boundary and security checks. This would allow an attacker to, for instance, cause speculative code in the normal hypercall / emulation path to execute with wild array indexes. "Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715): Poison the branch predictor. Well-abstracted code often involves calling function pointers via indirect branches; reading these function pointers may involve a (slow) memory access, so the CPU attempts to guess where indirect branches will lead. Poisoning this enables an attacker to speculatively branch to any code that is executable by the victim (eg, anywhere in the hypervisor). "Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754): On some processors, certain pagetable permission checks only happen when the instruction is retired; effectively meaning that speculative execution is not subject to pagetable permission checks. On such processors, an attacker can speculatively execute arbitrary code in userspace with, effectively, the highest privilege level. More information is available here: https://meltdownattack.com/ https://spectreattack.com/ https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html Additional Xen-specific background: Xen hypervisors on most systems map all of physical RAM, so code speculatively executed in a hypervisor context can read all of system RAM. When running PV guests, the guest and the hypervisor share the address space; guest kernels run in a lower privilege level, and Xen runs in the highest privilege level. (x86 HVM and PVH guests, and ARM guests, run in a separate address space to the hypervisor.) However, only 64-bit PV guests can generate addresses large enough to point to hypervisor memory. IMPACT == Xen guests may be able to infer the contents of arbitrary host memory, including memory assigned to other guests. An attacker's choice of code to speculatively execute (and thus the ease of extracting useful information) goes up with the numbers. For SP1, an attacker is limited to windows of code after bound checks of user-supplied indexes. For SP2, the attacker will in many cases will be limited to executing arbitrary pre-existing code inside of Xen. For SP3 (and other cases for SP2), an attacker can write arbitrary code to speculatively execute. Additionally, in general, attacks within a guest (from guest user to guest kernel) will be the same as on real hardware. Consult your operating system provider for more information. NOTE ON TIMING == This vulnerability was originally scheduled to be made public on 9 January. It was
[Xen-devel] I only see one CPU core on Xen when booted via grub
Hi, I only see 1 CPU core on Xen 4.9 when booted via grub instead of 8. It's may be related to : - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820807 - https://xenproject.atlassian.net/browse/XEN-42 It is the first server on which I have this problem. I can confirm that : - if I boot Debian througt grub, I see the 8 cores - if I boot Xen through grub, I only see _one_ core - if I boot Xen directly through EFI (using `efibootmgr`), I see the 8 cores 1. Do you know what happens ? 2. Do you need some logs ? Regards, Guillaume # cat /proc/cpuinfo model name : Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz microcode : 0x5e flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ht syscall nx lm constant_tsc arch_perfmon rep_good nopl nonstop_tsc eagerfpu pni pclmulqdq monitor est ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch epb fsgsbase bmi1 hle avx2 bmi2 erms rtm rdseed adx clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp # xl info release: 4.9.0-5-amd64 version: #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) xen_version: 4.8.3-pre # cat /etc/debian_version 9.3 _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] I only see one CPU core on Xen when booted via grub
... your report is very likely duplicating earlier ones where the ACPI root point cannot be found without it being properly propagated through by grub from EFI to Xen. Iirc the only way around that is to chainload xen.efi, if the grub used doesn't support the extensions needed to boot Xen via the multiboot2 protocol (support for which was added during the 4.9 development cycle). Thanks. So if I want to boot Xen through grub, I need Xen >= 4.9 and which version of grub ? Guillaume ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Xen EFI] Impossible to limit the dom0 memory
Hi, I have configured Xen to boot directly from EFI (with `efibootmgr`). As explained on the Xen_EFI wiki page, I have added a line "options=" into my file "/boot/efi/EFI/xen/xen.cfg" : ``` # cat /boot/efi/EFI/xen/xen.cfg : [global] default=xen [xen] options=dom0_mem=1G,max:1G kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash ramdisk=initrd.img ``` With the line `options=dom0_mem=1G,max:1G` the server reboot infinitely. Without the line `options=dom0_mem=1G,max:1G`, the server boot correctly, but obviously, the dom0 memory is in ballooning mode. I have attached a screen shot of the boot lines with the last lines I can see before the reboot. Unfortunately, I have nothing in kern.log. 1. Do you know what happens ? 2. Do you need some logs ? Regards, Guillaume Links : - https://wiki.xen.org/wiki/Xen_Project_Best_Practices#Xen_dom0_dedicated_memory_and_preventing_dom0_memory_ballooning - https://xenbits.xen.org/docs/4.8-testing/misc/xen-command-line.html - https://wiki.xen.org/wiki/Xen_EFI ``` # cat /proc/cpuinfo model name : Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz microcode : 0x5e flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ht syscall nx lm constant_tsc arch_perfmon rep_good nopl nonstop_tsc eagerfpu pni pclmulqdq monitor est ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch epb fsgsbase bmi1 hle avx2 bmi2 erms rtm rdseed adx clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp # xl info release: 4.9.0-5-amd64 version: #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) xen_version: 4.8.3-pre # cat /etc/debian_version 9.3 ``` ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory
Yet you'll need to provide the kernel messages I attached a console log "xen-console-log.txt". Here, Xen crash even without the "dom0_mem=1G,max:1G" option : ``` # cat /boot/efi/EFI/xen/xen.cfg [global] default=xen [xen] options=loglvl=all com1=115200,8n1 console=com1,vga kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash earlyprintk=xen console=com1 ramdisk=initrd.img ``` Do you need something else helpful ? Regards, Guillaume [0.00] node 0: [mem 0x1000-0x00057fff] [0.00] node 0: [mem 0x00059000-0x0009dfff] [0.00] node 0: [mem 0x0009f000-0x0009] [0.00] node 0: [mem 0x0010-0x881c5fff] [0.00] node 0: [mem 0x88211000-0x88282fff] [0.00] node 0: [mem 0x89fff000-0x89ff] [0.00] node 0: [mem 0x0001-0x000861ff] [0.00] Initmem setup node 0 [mem 0x1000-0x000861ff] [0.00] p2m virtual area at c900, size is 4000 [0.00] Remapped 491049 page(s) [0.00] ACPI: PM-Timer IO Port: 0x1808 [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1]) [0.00] IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-119 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] Using ACPI (MADT) for SMP configuration information [0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0 [0.00] smpboot: Allowing 8 CPUs, 0 hotplug CPUs [0.00] PM: Registered nosave memory: [mem 0x-0x0fff] [0.00] PM: Registered nosave memory: [mem 0x00058000-0x00058fff] [0.00] PM: Registered nosave memory: [mem 0x0009e000-0x0009efff] [0.00] PM: Registered nosave memory: [mem 0x000a-0x000f] [0.00] PM: Registered nosave memory: [mem 0x881c6000-0x881c6fff] [0.00] PM: Registered nosave memory: [mem 0x881c7000-0x88210fff] [0.00] PM: Registered nosave memory: [mem 0x88283000-0x89ec1fff] [0.00] PM: Registered nosave memory: [mem 0x89ec2000-0x89f99fff] [0.00] PM: Registered nosave memory: [mem 0x89f9a000-0x89ffefff] [0.00] PM: Registered nosave memory: [mem 0x8a00-0x8bff] [0.00] PM: Registered nosave memory: [mem 0x8c00-0x8fff] [0.00] PM: Registered nosave memory: [mem 0x9000-0x95ff] [0.00] PM: Registered nosave memory: [mem 0x9600-0x97ff] [0.00] PM: Registered nosave memory: [mem 0x9800-0x9dff] [0.00] PM: Registered nosave memory: [mem 0x9e00-0xe00f9fff] [0.00] PM: Registered nosave memory: [mem 0xe00fa000-0xe00fafff] [0.00] PM: Registered nosave memory: [mem 0xe00fb000-0xe00fcfff] [0.00] PM: Registered nosave memory: [mem 0xe00fd000-0xe00fdfff] [0.00] PM: Registered nosave memory: [mem 0xe00fe000-0xfdff] [0.00] PM: Registered nosave memory: [mem 0xfe00-0xfe010fff] [0.00] PM: Registered nosave memory: [mem 0xfe011000-0xfebf] [0.00] PM: Registered nosave memory: [mem 0xfec0-0xfec00fff] [0.00] PM: Registered nosave memory: [mem 0xfec01000-0xfed8] [0.00] PM: Registered nosave memory: [mem 0xfed9-0xfed90fff] [0.00] PM: Registered nosave memory: [mem 0xfed91000-0xfedf] [0.00] PM: Registered nosave memory: [mem 0xfee0-0xfeef] [0.00] PM: Registered nosave memory: [mem 0xfef0-0x] [0.00] e820: [mem 0x9e00-0xe00f9fff] available for PCI devices [0.00] Booting paravirtualized kernel on Xserve-AD) [0.00] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 7645519600211568 ns [0.00] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:8 nr_node_ids:1 [0.00] percpu: Embedded 35 pages/cpu @88083ec0 s105304 r8192 d29864 u262144 [0.00] PV qspinlock hash table entries: 256 (order: 0, 4096 bytes) [0.00] Built 1 zonelists in Node order, mobility grouping on. Total pages: 8169272 [0.00] Policy zone: Normal [0.00] Kernel command line: root=/dev/md2 ro rootdelay=10 noquiet nosplash earlyprintk=xen console=com1 [0.00] PID hash table entries: 4096 (order: 3, 32768 bytes) [0.00] software IO TLB [mem 0x83ac0-0
Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory
Xen doesn't crash at all. With this file, it works, Xen boots : ``` [global] default=xen [xen] options=loglvl=all com1=115200,8n1 console=com1,vga kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash earlyprintk=xen ramdisk=initrd.img ``` With this file, I have just added "dom0_mem=1G,max:1G", Xen crashes : ``` [global] default=xen [xen] options=loglvl=all com1=115200,8n1 console=com1,vga dom0_mem=1G,max:1G kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash earlyprintk=xen ramdisk=initrd.img ``` I attached the boot logs "dom0_crash_with_dom0_memory.txt". The last line is "(XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds." Do you need something else helpful ? _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory
(With the attached file)
Xen doesn't crash at all.
With this file, it works, Xen boots :
```
[global]
default=xen
[xen]
options=loglvl=all com1=115200,8n1 console=com1,vga
kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash
earlyprintk=xen
ramdisk=initrd.img
```
With this file, I have just added "dom0_mem=1G,max:1G", Xen crashes :
```
[global]
default=xen
[xen]
options=loglvl=all com1=115200,8n1 console=com1,vga dom0_mem=1G,max:1G
kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash
earlyprintk=xen
ramdisk=initrd.img
```
I attached the boot logs "dom0_crash_with_dom0_memory.txt". The last
line is "(XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds."
Do you need something else helpful ?
Regards,
Guillaume
Le 24/01/2018 à 08:43, Jan Beulich a écrit :
On 23.01.18 at 18:43, wrote:
Yet you'll need to provide the kernel messages
I attached a console log "xen-console-log.txt".
Here, Xen crash even without the "dom0_mem=1G,max:1G" option :
Xen doesn't crash at all. It's the Dom0 kernel which panics, but
the log doesn't tell me why it does (other than _something_
having tried to exit the init process). This doesn't look Xen related
at all with the provided information.
Jan
Xen 4.8.3-pre (c/s ) EFI loader
Using configuration file 'xen.cfg'
vmlinuz: 0x82578000-0x82a16710
initrd.img: 0x80ef3000-0x82577165
0x:0x02:0x00.0x0: ROM: 0x11000 bytes at 0x85312018
0x:0x03:0x00.0x0: ROM: 0x11000 bytes at 0x85300018
(XEN) Xen version 4.8.3-pre (Debian 4.8.2+xsa245-0+deb9u1)
(ijack...@chiark.greenend.org.uk) (gcc (Debian 6.3.0-18) 6.3.0 20170516)
debug=n Sat Nov 25 11:30:34 UTC 2017
(XEN) Bootloader: EFI
(XEN) Command line: loglvl=all com1=115200,8n1 console=com1,vga
dom0_mem=1G,max:1G
(XEN) Video information:
(XEN) VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 2 EDD information structures
(XEN) EFI RAM map:
(XEN) - 00058000 (usable)
(XEN) 00058000 - 00059000 (reserved)
(XEN) 00059000 - 0009e000 (usable)
(XEN) 0009e000 - 0009f000 (reserved)
Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory
# About the kernel crash Did you read the above? I just wanted to say that I have solved the kernel panic crash that I had before, when you explained "Xen doesn't crash at all. It's the Dom0 kernel which panics". Just for information the crash happens if I put the "console=com1" to the kernel command line. ``` kernel=vmlinuz root=/dev/md2 ro rootdelay=10 noquiet nosplash earlyprintk=xen console=com1 ``` And this, I understand, is not linked to Xen. # About the Xen Dom0 crash This tells us (together with the page fault error code) that the Dom0 kernel tried to provide memory as kernel stack which can't be written. This may be a Dom0 kernel stack overflow, but there may also be other reasons. At this point I can't exclude there being some root cause in Xen, but the issue needs to be investigated from the Dom0 kernel side. I have tested with the version 4.9 and 4.14 of the kernel from Debian and the crash occurs when there is the option "dom0_mem=1G,max:1G". https://packages.debian.org/stretch/linux-image-amd64 https://packages.debian.org/stretch-backports/linux-image-amd64 Do you want that I test something else ? Regards, Guillaume _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory
Guillaume, can you try to get symbol+offset for the values on the stack looking like kernel code addresses (e.g. everything starting with "82")? For sure. Just, can you explain me how I can do this, please ? Guillaume _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory
I have installed `linux-image-amd64-dbg` and `binutils`. I can now execute `addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 `. I have generated a file "commands.txt" with all the addresses after "Guest stack trace from rsp=82003cb0:" in my log file "dom0_crash_with_dom0_memory.txt". I attached the result : "result.txt". We can see inside this file "xen/mmu_pv.c:1548" and "drivers/firmware/efi/efi.c:558", so I hope it will be helpful. Is that ok for you ? Can I do something more ? Regards, Guillaume addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0010 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 303030363838 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0003 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8240723c addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0001e030 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 00010086 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003cf0 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 e02b addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8241c3ef addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 86bb5000 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0001 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824355f9 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0af0 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 1000 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8163 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 05be82003d38 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 86bb5af0 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0010 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0018 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 000c addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 885f2e18 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 000c addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8243582e addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 ff2001f8 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003de0 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8245400f addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824355f9 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824c6fc0 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 45963d3ad719b2cb addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 6f65670ed0dabca3 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 05fe addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0018 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003df8 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 ff2000d8 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824c6fc0 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0018 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824540e3 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824540e3 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 ff200260 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 024ac1e0 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003f18 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8241fa00 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 204b444582003f18 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 20534f4942204949 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 30303231533a4449 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 302e4236382e5053 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 3230302e31302e33 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 3032373239302e36 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 393237303731 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0100 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8100 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8240a82a addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 810d12fd addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0010 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003f18 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003ed0 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 000
Xen Security Advisory 334 v3 (CVE-2020-25598) - Missing unlock in XENMEM_acquire_resource error path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-25598 / XSA-334 version 3 Missing unlock in XENMEM_acquire_resource error path UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar to forgetting to unlock a spinlock. IMPACT == A buggy or malicious HVM stubdomain can cause an RCU reference to be leaked. This causes subsequent administration operations, (e.g. CPU offline) to livelock, resulting in a host Denial of Service. VULNERABLE SYSTEMS == The buggy codepath has been present since Xen 4.12. Xen 4.14 and later are vulnerable to the DoS. The side effects are believed to be benign on Xen 4.12 and 4.13, but patches are provided nevertheless. The vulnerability can generally only be exploited by x86 HVM VMs, as these are generally the only type of VM which have a Qemu stubdomain. x86 PV and PVH domains, as well as ARM VMs typically don't use a stubdomain. Only VMs using HVM stubdomains can exploit the vulnerability. VMs using PV stubdomains, or with emulators running in dom0 cannot exploit the vulnerability. MITIGATION == Running only x86 PV or PVH VMs will avoid the vulnerability. Reconfiguring x86 HVM guests to use a PV or no stubdom will also avoid the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa334.patch Xen 4.13 - xen-unstable xsa334-4.12.patch Xen 4.12 $ sha256sum xsa334* 80e7725a56c4244d860e9aebb56710a8165f7ffeae3fb67365cbc85b3b0518b3 xsa334.meta 323cd9d24b2e95643833865a9943172c56edd25dfd170e4741034d28dfd0d4bd xsa334.patch 85341ba6322ea6279c0851493ce61e822c8560850034f5f26cbcb26be85ca102 xsa334-4.12.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/eYMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZV94H/jhwML6zObPz+zvjbwwAUoHsYiQ66CSUlxluqjN5 PXWpm56RzArptGIUakQyXKNI2Ht2fUn3Lu3w9JllujJRfmhbhiJJvI9Ar2QzOcri +XylcK9rRspfmNUgXB629BTEcGUuo9/J+T+O4T544zfWUBncixyDq9/Q9SGAdz9c kDZkL6UebpIFLtD6jrgYd4XAK9b1c6T7SmsGzq26m/zwGqJ1jol58kHl5GMXe7uX rd9xZbERKIhaABbTQ10zY5IDIE4oplibSLOiJVSTz6KSyzD9by+M7oszqeIbIiRV rY49lettdD4jfmzp5bbXQnf+9T31rG3AEHWaiOGdVcRFoq8= =a23E -END PGP SIGNATURE- xsa334.meta Description: Binary data xsa334.patch Description: Binary data xsa334-4.12.patch Description: Binary data
Xen Security Advisory 333 v3 (CVE-2020-25602) - x86 pv: Crash when handling guest access to MSR_MISC_ENABLE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-25602 / XSA-333 version 3 x86 pv: Crash when handling guest access to MSR_MISC_ENABLE UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = When a guest accesses certain Model Specific Registers, Xen first reads the value from hardware to use as the basis for auditing the guest access. For the MISC_ENABLE MSR, which is an Intel specific MSR, this MSR read is performed without error handling for a #GP fault, which is the consequence of trying to read this MSR on non-Intel hardware. IMPACT == A buggy or malicious PV guest administrator can crash Xen, resulting in a host Denial of Service. VULNERABLE SYSTEMS == Only x86 systems are vulnerable. ARM systems are not vulnerable. Only Xen versions 4.11 and onwards are vulnerable. 4.10 and earlier are not vulnerable. Only x86 systems which do not implement the MISC_ENABLE MSR (0x1a0) are vulnerable. AMD and Hygon systems do not implement this MSR and are vulnerable. Intel systems do implement this MSR and are not vulnerable. Other manufacturers have not been checked. Only x86 PV guests can exploit the vulnerability. x86 HVM/PVH guests cannot exploit the vulnerability. MITIGATION == Running only HVM/PVH guests avoids the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa333.patch Xen 4.11 - xen-unstable $ sha256sum xsa333* 3f3d974ede9fe80f4eb63640dce058cf9e2073cd79e4c085c944f3ca5e454e26 xsa333.meta 8edec914fbdf036fba8cb54a75d3a9b025fac936e0af35512954a2dc2b12a26f xsa333.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/eUMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZu5EH/RAaLJocX5UJfEZ4QT2osvnc1aaZjBXNz4JN1HDj 46pGxBOv1kEDxBu/lqbbXEY2aLeBLder2nj0OHCYgDkPCh4fqaciBqCEO97COqzo dFvN17dZ0pjyBUoSXs8mVPWjMblBjf6/Mt+/gh8speJQ32V3lHz6xYc9Nu0CVoL5 +RiaRVPGYOVndF5A0XK6UIiiMAOcVgPHpg485QFT2EIVPlKVu/jDrrsYep/9OrmP bamEjKcYoFBBsMlpUNAtUK0QZGnSAe2vVtbUNeHgY5T5BDuJzLZXdMDGmBDXK2vV 0PNMOoIeFev6Pq7yuvvTqI0PKEBmO825hkbZ5sEva/7pZ60= =zf3E -END PGP SIGNATURE- xsa333.meta Description: Binary data xsa333.patch Description: Binary data
Xen Security Advisory 339 v3 (CVE-2020-25596) - x86 pv guest kernel DoS via SYSENTER
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-25596 / XSA-339 version 3 x86 pv guest kernel DoS via SYSENTER UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP fault (usually converted into SIGSEGV/etc). IMPACT == Malicious or buggy userspace can crash the guest kernel, resulting in a VM Denial of Service. VULNERABLE SYSTEMS == All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems are vulnerable. ARM platforms are not vulnerable. Only x86 systems which support the SYSENTER instruction in 64bit mode are vulnerable. This is believed to be Intel, Centaur and Shanghai CPUs. AMD and Hygon CPUs are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests cannot exploit the vulnerability. MITIGATION == Running only x86 PVH / HVM guests avoids the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa339.patch Xen 4.10 - xen-unstable $ sha256sum xsa339* 5cece13878cc40b32bc5753c0ef64f989f9b1c7f9549d62ea4fcd06e9620de9e xsa339.meta b6ffa7671d905aa12498ad64915be3b7cba74ce1c5bf6bce18b1f106ebf6d715 xsa339.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZgEUH/1/5DUgXRKzwvYuERdBintUdCUaezYpjY0VEJ/v5 nPXEZDDkBFZZxtWmLg6gqMsJg4O6npTcZ6Z3ZpP8xTiRexr0fHHRY5FHqOCW0aS+ c0WYQzSvfDW1L/m9fjwsbFKKRCmrwE24L/Jc7GZJlpps22f1mZpn3cwsjidlofHi WxqpdAPNDLsPDF3+iwt5a8gL3onyeo03MaBhO29UAJIKCo4hxiKu5/e3upXFBdN2 Z4Pyr79E51SiCGxZ/A1NTil9+FyYkP1DgBQdJ6pVrxMnZUhdcjbGLEbrUNaTfgox yORU8rE3XS2ZajRpW3D2CIGnKJj3zGWaQqx+FufX1m6Y8qE= =tkQp -END PGP SIGNATURE- xsa339.meta Description: Binary data xsa339.patch Description: Binary data
Xen Security Advisory 336 v3 (CVE-2020-25604) - race when migrating timers between x86 HVM vCPU-s
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-25604 / XSA-336 version 3 race when migrating timers between x86 HVM vCPU-s UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = When migrating timers of x86 HVM guests between its vCPU-s, the locking model used allows for a second vCPU of the same guest also operating on the timers to release a lock that it didn't acquire. IMPACT == The most likely effect of the issue is a hang or crash of the hypervisor, i.e. a Denial of Service (DoS). VULNERABLE SYSTEMS == All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability. MITIGATION == Running only PV and PVH guests will avoid the vulnerability. CREDITS === This issue was discovered by Igor Druzhinin of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa336.patch Xen 4.12 - xen-unstable xsa336-4.11.patch Xen 4.10 - 4.11 $ sha256sum xsa336* 6cb13a54c2b0fcb6948a1c4045095da4e43aad262a1dd8993ea2a3bd90d4c72d xsa336.meta ecb59876fb92cfe0916ed5f3227a30efe038224c1f6ec36bc3706c4e2214552c xsa336.patch c0c7983bfd70eb54277af9fddfcc3cc95bbd745d92d9ffb71d5b32281c437510 xsa336-4.11.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/eYMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZe28H/3oTZLe4eVhykU7a+BbN7ENJ2WMYsj0VM5wUiQyK ZrY3CnbO0ne6h0BeAgSNG1XRP9QvwJLOIm6gZkqoNCWyJK2IbCO/mlF4czBlpUBR FtM2wJz4FLzkiYMozk8TOZk6pCW6gaqxNiYr2L/3ijh2PQCMwnte/u+T3mZAAWxB nJbVnwux26nvRY/5XBZ7cZ/Qxi1DKed2cyf2A9oZ/AmGIMBT2r6SZ+arf+d4jHRG yQok+7gdXr1lOL/pPZZWepHtbPJMrrYxQZN/zKGt20c9ksBLiOyyQxTO4tegLx7N PxRgzy+DgY+xqYFA68xpM6jJxfWYmHpjAtbYtQoPvyPsIag= =0Kkw -END PGP SIGNATURE- xsa336.meta Description: Binary data xsa336.patch Description: Binary data xsa336-4.11.patch Description: Binary data
Xen Security Advisory 338 v4 (CVE-2020-25597) - once valid event channels may not turn invalid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-25597 / XSA-338 version 4 once valid event channels may not turn invalid UPDATES IN VERSION 4 Public release. ISSUE DESCRIPTION = Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. IMPACT == An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. VULNERABLE SYSTEMS == All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems using exlusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting max_event_channels, are not vulnerable. MITIGATION == The problem can be avoided by reducing the number of event channels available to the guest to no more than 1023. For example, setting "max_event_channels=1023" in the xl domain configuration, or deleting any existing setting (since 1023 is the default for xl/libxl). For ARM systems, any limit no more than 4095 is safe. For 64-bit x86 PV guests, any limit no more than 4095 is likewise safe if the host configuration prevents the guest administrator from substituting and running a 32-bit kernel (and thereby putting the guest into 32-bit PV mode). CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa338.patch Xen 4.10 - xen-unstable $ sha256sum xsa338* 56c322b89a96db6be40cf15fdb9303e24ff692aa5a6274b2d7718bfc05acf309 xsa338.meta 7345eac1cbad23b082523e9cbd0331f8a9f16c6e459fb2a686606253f5514c9b xsa338.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the *patch* described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). And: deployment of the event channel limit reduction mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because such a change can be visible to the guest, so it would leak the preconditions for the vulnerability and maybe lead to rediscovery. Deployment of this, or similar mitigations, is permitted only AFTER the embargo ends. Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZlToIAMY5ZvKvqVmLzy/UEZrq3lgf8DA2+n9BFnec+XlI gDz7ssJNgwnkrrt7BF/XGeaAwly/pRACLapYd7hP8KNM3qPz/DG++S2FS/O44AkQ 7yjYRoEJRxFK1RnG3UeVw9S8aDrUrsTIoh7WFsX7rvEw6zg6o4kii4YSjvUSV5ug uYh0p3i56CWqjlKd94ZQlESfacrl1wZd/AemdDbAzj/FMF0ZyQujQ3PHBAcLjbPR jzE/EJRjpEPe9kMWKDWX06VlWja6cUDFIlaqZM9nlgiyI643y2iRSuilQbansMPA zG6SXQOqzSWc+OQ3wUaf972mjNfiKiBSFo/hB95HdS5I2Pk= =EzUa -END PGP SIGNATURE- xsa338.meta Description: Binary data xsa338.patch Description: Binary data
Xen Security Advisory 342 v3 (CVE-2020-25600) - out of bounds event channels available to 32-bit x86 domains
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-25600 / XSA-342 version 3 out of bounds event channels available to 32-bit x86 domains UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains can use only 1023 channels, due to limited space in their shared (between guest and Xen) information structure, whereas all other domains can use up to 4095 in this model. The recording of the respective limit during domain initialization, however, has occurred at a time where domains are still deemed to be 64-bit ones, prior to actually honoring respective domain properties. At the point domains get recognized as 32-bit ones, the limit didn't get updated accordingly. Due to this misbehavior in Xen, 32-bit domains (including Domain 0) servicing other domains may observe event channel allocations to succeed when they should really fail. Subsequent use of such event channels would then possibly lead to corruption of other parts of the shared info structure. IMPACT == An unprivileged guest may cause another domain, in particular Domain 0, to misbehave. This may lead to a Denial of Service (DoS) for the entire system. VULNERABLE SYSTEMS == All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only x86 32-bit domains servicing other domains are vulnerable. Arm systems as well as x86 64-bit domains are not vulnerable. MITIGATION == There is no known workaround for x86 32-bit Domain 0. The problem can be avoided by reducing the number of event channels available to 32-bit x86 guests to no more than 1023. For example, setting "max_event_channels=1023" in the xl domain configuration, or deleting any existing setting (since 1023 is the default for xl/libxl). CREDITS === This issue was discovered by Julien Grall of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa342.patch Xen 4.14 - xen-unstable xsa342-4.13.patch Xen 4.10 - 4.13 $ sha256sum xsa342* 8e85719f2783d5d0fc3da7a6aefb6c83717c7aa195d027b6aa52ff3a31c489aa xsa342.meta 060caee3fb5971fca0f2fbdef622c52d9bc6e0ed9efad33de5b6b504651c2112 xsa342.patch ef34839148d33b8d9cb03d56ffafdcdcbe9641a737211a50343d019132b169dd xsa342-4.13.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ+RAIAKhulm14Ze1LmVTCGKcTJ525DARSmzGdki4iX3ow qvQkV1B8TacFnuzZp1VfRnm5vRGBY/uXaFORw21Z/rWSRQ3xjgcazTsG0jhNQ8QG onH1JaxE26BfYu12oTSEKyTWWu1XSdrFTxWp07p79+qHvKGY6GtGRWGhkI6YNgkD X2TwRtt6GF6wRTq3PCc+7CGnn5jp7FRyJpI/2uiNZC6cL6lGUYNl9wgujSnefqQO 1sAZSc3DmvIuvFl4XWUeU7mH/6xL93sDN4vIrVllvcI9nEswqFwju6+SP76Pnkoh KBSYNk79QNlbBdXJwNmYxqp4sYpH/JYEm6+u2Zw1hxCMgM4= =EebG -END PGP SIGNATURE- xsa342.meta Description: Binary data xsa342.patch Description: Binary data xsa342-4.13.patch Description: Binary data
Xen Security Advisory 340 v3 (CVE-2020-25603) - Missing memory barriers when accessing/allocating an event channel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-25603 / XSA-340 version 3 Missing memory barriers when accessing/allocating an event channel UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Event channels control structures can be accessed lockless as long as the port is considered to be valid. Such sequence is missing appropriate memory barrier (e.g smp_*mb()) to prevent both the compiler and CPU to re-order access. IMPACT == A malicious guest may be able to cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. Whether a system is vulnerable will depend on the CPU and compiler used to build Xen. For all the systems, the presence and the scope of the vulnerability depends on the precise re-ordering performed by the compiler used to build Xen. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU vendor. x86 systems are only vulnerable if a compiler performs re-ordering. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Julien Grall of Amazon. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa340.patch Xen 4.10 - xen-unstable $ sha256sum xsa340* 72b75011b99e914ddb479082f88329063dcd1f55cc931059d950ecda276ee944 xsa340.meta 2bb088fcc1f8f79bf5ddb7b4e101cb1db76a343d2fb1cdafb7cd54612e4009da xsa340.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZaBsH/RbQVpTAfl0zd7RyKXO34WZnWsYfwC+l8erEtf51 rmETfcqQP5rjNZZKEIDWcoYbJQU1DdC5tfVarUEYbGzCxPyBXlckcNKWmIVpkWnC i+/XBALNjErN3AoJJOc8Tb3nfOZJlRrh3PXaqFo+xOqBn2vijgQJCXlpr1yRLDov CatUy5DWmzVWVgByrkHs9Y+hsK7hb+DzxFvNiZUE7kv8a+R3F3smNgXDe/N7AasL ZCJNVpfJGjqpk+EnffaTti9gd2aPxxzzmsWAoiW0C/6s/eJckhj/LxF7ZG5WbuVT inhxm6zkQwBwvSTM7GLZpOuPXPegI8/RX+fO6lqsD0bcuQo= =J1Xd -END PGP SIGNATURE- xsa340.meta Description: Binary data xsa340.patch Description: Binary data
Xen Security Advisory 344 v4 (CVE-2020-25601) - lack of preemption in evtchn_reset() / evtchn_destroy()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-25601 / XSA-344 version 4 lack of preemption in evtchn_reset() / evtchn_destroy() UPDATES IN VERSION 4 Public release. ISSUE DESCRIPTION = In particular the FIFO event channel model allows guests to have a large number of event channels active at a time. Closing all of these when resetting all event channels or when cleaning up after the guest may take extended periods of time. So far there was no arrangement for preemption at suitable intervals, allowing a CPU to spend an almost unbounded amount of time in the processing of these operations. IMPACT == Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the entire system. VULNERABLE SYSTEMS == All Xen versions are vulnerable in principle. Whether versions 4.3 and older are vulnerable depends on underlying hardware characteristics. MITIGATION == The problem can be avoided by reducing the number of event channels available to all guests to a suitably low limit. For example, setting "max_event_channels=256" in the xl domain configurations may be low enough for all hardware Xen is able to run on. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa344/xsa344-?.patch Xen 4.14 - xen-unstable xsa344/xsa344-4.13-?.patch Xen 4.13 xsa344/xsa344-4.12-?.patch Xen 4.12 xsa344/xsa344-4.11-?.patch Xen 4.11 xsa344/xsa344-4.10-?.patch Xen 4.10 $ sha256sum xsa344* xsa344*/* 74ae97a618a3680920bed131e69656d5a7c039efbbec99b55b99af772e3e87df xsa344.meta 5f9dbdc48bed502d614a76e5819afa41a72cec603c5a2c9491d73873a991a5ed xsa344/xsa344-1.patch 381ca5c51bc120bfd5c742be3988f570abb870c4b75c8a48cf49ae4fa1046d73 xsa344/xsa344-2.patch b52e4ecd6db8c3c6ebc0ab6facbd0f4fa0859657d13491819c3279fe439f66ec xsa344/xsa344-4.10-1.patch 53ca9c954fd73344968f40689b0d0ea583bd19ece72166fd2d4eaa125b82f26f xsa344/xsa344-4.10-2.patch 7abea30b406b0a572f7cd76bd9768d12262344a8e255ddd29d2ad893724638a0 xsa344/xsa344-4.11-1.patch f2b39146ac410154043efd09880277e4e821a1dd47a0bd3000545e5568253b97 xsa344/xsa344-4.11-2.patch a654c99f5d1c25d9d12ba267d2db10b0a1e0da337ce334fb5aafa6b2061ebc3c xsa344/xsa344-4.12-1.patch 6af4e05f8536b11a3dc4c70620b8ed973ecf09efd4c64eb500f6363d5f0402e7 xsa344/xsa344-4.12-2.patch 9b81c7cf3cd33f9d43c43222a0434a8d4e0acff74f339a6842f16bfa2f304cb5 xsa344/xsa344-4.13-1.patch 80a41b7e08cdb54a28dfc82630a0d8d89fc25e381bc4505ed41017a760addf09 xsa344/xsa344-4.13-2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/egMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ114H/2QrxpADKwxDb2+aL8fhf46AJYwgxDa8SoI18INd IVeHs8Lq4CQsfSFxBbXOWDGo82bUg43kwcdZ3ToSaX2JSC4R3r0us6tSdaRIqpNj sQo56ozFXH63v4zTlB8gF58skm2n+CZQ5nKccnTUsN7KuqfPWm/2LfBnqnHYkYQ9 CVHBG5YXMnrHbASo+HglGqjgu6GyEsLoJpSQEj6oYF/UW86OYeAwZ2TFAFVZ/T04 XtxnH7aYCSMOeQRPU6BnCdoVKg/wn4ilSKyqYAin8uNFf7af3OSSCR4FTYkLX+VG WYJnc27SUAb28+l9f65r8cwzs2+O5SlqhpqyS6xcM3A1248= =UYAk -END PGP SIGNATURE- xsa344.meta Description: Binary data xsa344/xsa344-1.patch Description: Binary data xsa344/xsa344-2.patch Description: Binary data xsa344/xsa344-4.10-1.patch Description: Binary data xsa344/xsa344-4.10-2.patch Description: Binary data xsa344/xsa344-4.11-1.patch Description: Binary data xsa344/xsa344-4.11-2.patch Description: Binary data xsa344/xsa344-4.12-1.patch Description: Binary data xsa344/xsa344-4.12-2.patch Description: Binary data xsa344/xsa344-4.13-1.patch Description: Binary data
Xen Security Advisory 337 v3 (CVE-2020-25595) - PCI passthrough code reading back hardware registers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-25595 / XSA-337
version 3
PCI passthrough code reading back hardware registers
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
Code paths in Xen's MSI handling have been identified which act on
unsanitized values read back from device hardware registers. While
devices strictly compliant with PCI specifications shouldn't be able to
affect these registers, experience shows that it's very common for
devices to have out-of-spec "backdoor" operations which can affect the
result of these reads.
IMPACT
==
A not fully trusted guest may be able to crash Xen, leading to a Denial
of Service (DoS) for the entire system. Privilege escalation and
information leaks cannot be excluded.
VULNERABLE SYSTEMS
======
All versions of Xen supporting PCI passthrough are affected.
Only x86 systems are vulnerable. Arm systems are not vulnerable.
Only guests with passed through PCI devices may be able to leverage
the vulnerability.
Only systems passing through devices with out-of-spec ("backdoor")
functionality can cause issues. Experience shows that such out-of-spec
functionality is common; unless you have reason to believe that your
device does not have such functionality, it's better to assume that it
does.
REMINDER OF PCI PASSTHROUGH SUPPORT STATEMENT
=
The security team wishes to reiterate our support statement for PCI
Device Passthrough (found in xen.git/SUPPORT.md):
"Because of hardware limitations (affecting any operating system or
hypervisor), it is generally not safe to use this feature to expose a
physical device to completely untrusted guests. However, this feature
can still confer significant security benefit when used to remove
drivers and backends from domain 0 (i.e., Driver Domains)."
The possibility of "backdoor" device functionality mentioned above is
one of the major reasons for this stance. We issue this XSA to help
maintain Driver Domains as a "defense-in-depth", and also on behalf of
those who may have done full security audits of their particular
hardware platform. It does not change our stance that passing through
PCI devices to untrusted guests is in general not safe.
MITIGATION
==
Not passing through physical devices to untrusted guests will avoid
the vulnerability.
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the appropriate pair of attached patches resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa337/xsa337-?.patch Xen 4.14 - xen-unstable
xsa337/xsa337-4.13-?.patch Xen 4.13
xsa337/xsa337-4.12-?.patch Xen 4.10 - 4.12
$ sha256sum xsa337* xsa337*/*
f027d07fb307f5441ee9d19b6385e421bba745059667d181031b0bfd7047a15b xsa337.meta
98c48781dd46bf6ff6cc46246c6c9f2e2be6ec696c0e7918d4b82845588ce04e
xsa337/xsa337-1.patch
9e8ae24222371379f2ea62e14fcc7f7282e01c356dff230c22c9ab1d2fb941e2
xsa337/xsa337-2.patch
a6744fdab01877e098f88dcd3bee10c3146aef66170a1422b3811cd09fc9faef
xsa337/xsa337-4.12-1.patch
a091652f1a3c0bf851e35b61d338d53b4690fab828b3c30f354c28c377af2aee
xsa337/xsa337-4.12-2.patch
fb27fd2508e017bf05131eb3d31bb8cc56c79690cbb7f1af76cb92fd568040a1
xsa337/xsa337-4.13-1.patch
a25bc70ad55716ce3a0d9435fa2b0a492420a0eabfb0e3f94cd27de10242d98b
xsa337/xsa337-4.13-2.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.
HOWEVER, deployment of the mitigation is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List). Specifically, deployment on public cloud systems
is NOT permitted.
This is because removing of pass-through devices or their replacement by
emulated devices is a guest visible configuration change, which may lead
to re-discovery of the issue.
Deployment of this mitigation is permitted only AFTER the embargo ends.
AND: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is
Xen Security Advisory 313 v3 (CVE-2020-11740,CVE-2020-11741) - multiple xenoprof issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-11740,CVE-2020-11741 / XSA-313 version 3 multiple xenoprof issues UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Unprivileged guests can request to map xenoprof buffers, even if profiling has not been enabled for those guests. These buffers were not scrubbed. This is CVE-2020-11740. Furthermore, for guests for which "active" profiling was enabled by the administrator, the xenoprof code uses the standard Xen shared ring structure. Unfortunately, this code did not treat the guest as a potential adversary: it trusts the guest not to modify buffer size information or modify head / tail pointers in unexpected ways. This is CVE-2020-11741. IMPACT == A malicious guest may be able to access sensitive information pertaining to other guests. Guests with "active profiling" enabled can crash the host (DoS). Privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == Only x86 PV guests can leverage the vulnerabilities. Arm guests and x86 HVM and PVH guests cannot leverage the vulnerabilities. All Xen versions back to at least 3.2 are vulnerable. Any x86 PV guest can leverage the information leak. Only x86 PV guests whose host administrator has explicitly enabled "active profiling" for an untrusted guest can exploit the DoS / potential privilege escalation. Only builds of Xen with the Xenoprof functionality enabled at build time are vulnerable. The option to disable the functionality at build time was been introduced in Xen 4.7. MITIGATION == Never making any untrusted guests "active" will avoid all but the info leak part of the vulnerabilities. There's no known mitigation for the information leak (lack of scrubbing). CREDITS === This issue was discovered by Ilja Van Sprundel of IOActive. RESOLUTION == Applying the attached set of patches resolves these issues. The first patch fixes the information leak issue, and should be applied to all x86 systems running untrusted PV guests. The second patch fixes the "active profiling" issue. Systems which do not enable active profiling can safely skip patch 2. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa313-?.patch xen-unstable, Xen 4.9.x - 4.13.x $ sha256sum xsa313* 63a11c5470a6c24f19d3a8a45042306256e7422d6556e3d76badaa515deb76d6 xsa313.meta f186ad88b492b730aeae3bd01083dd6c13813ce08bcd4ffc608d7af500633a62 xsa313-1.patch 9fbcb5f11e5029e7d371ddb3520443c2780f240edc3d24436872935e34a85c37 xsa313-2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl6VpdkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZYZcH/0UHo2zmXGMDvZn1EF20ccKXNoZjvAE5TxSr/A/M qkeASj4IMKlrPOrvs7aQSp97vECTz71Fxz2z7wpGwgIdiOYcRVg/t3b/+E1QSx5N T7xYxxD9ULOLBQyPjYnXYwDC9+9yy+PZuWt3oPeXHrdtLI/5VY/gCzU+k+7bDABh uljJ5KqxeQ5W8DOCR+XscQSZ9wiSkyh8MANjuJJ7uhtVDBo+ul94lrInJYEaBVpI At5cU53B5nVGQ3RkNyWKjSW3VbL1TLgTdWAJNQOo+Z0OZJiKm6xQ6OYph2L4C4j4 e5A5c8UZAXLxVFWIMuiRW2GekOQEkGXtu+uJP00GuXm3+cQ= =1C0J -END PGP SIGNATURE- xsa313.meta Description: Binary data xsa313-1.patch Description: Binary data xsa313-2.patch Description: Binary data
Xen Security Advisory 314 v3 (CVE-2020-11739) - Missing memory barriers in read-write unlock paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-11739 / XSA-314 version 3 Missing memory barriers in read-write unlock paths UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. IMPACT == A malicous guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. Whether an individual Arm-based CPU is vulnerable depends on its memory re-ordering properties. Consult your CPU vendor. x86 systems are not vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Julien Grall of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa314.patch xen-unstable xsa314-4.13.patch Xen 4.13 - Xen 4.9 $ sha256sum xsa314* ff6e03780766d0358699ed0c5b0154be9ccbbc80796650f7568c295c5451ba0a xsa314.meta 7c507e7b46568e94aa9595a549bd3020b16d1eca97b8bfc3bb1f5d96eb338cc1 xsa314.patch a13e6a9cd531859882d1b0ef38245441d363d1ead1fa2a5ae5da7a0fce27e072 xsa314-4.13.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl6VpdcMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZNSoH/2TB+nP1KWB0LUkP5yD1tlSC6Q58k3ReUw7uVfLh OOBhyOZz5jQOO9r6HDQtqxZBtihbmCDD9Ckl3V4au81TFxz8My24nMR+X1dqDcPi 0MQ2+Tu3z6S/NMw9DwLsN9b0MtHlmalOBrhbhif3/U0QDgLFhN2H8GtvFQ1imWmm JHoTdBHDUwxCvThIHZCui/T69U/csdfyV6f/HgMVTzpNIOBkiwUuOVuMEO25KqVk tO0z0CyK19K86VJu7k4q16RzCllUoe5bSU+7UVYOS1PxZ5XCvKTCYcZDz1HZMW/8 FOA8yNMzHV3b+0WvCnMpq9qHmmJXGx+vRSoeBF7YeU0wUkE= =oA9H -END PGP SIGNATURE- xsa314.meta Description: Binary data xsa314.patch Description: Binary data xsa314-4.13.patch Description: Binary data
Xen Security Advisory 318 v3 (CVE-2020-11742) - Bad continuation handling in GNTTABOP_copy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-11742 / XSA-318 version 3 Bad continuation handling in GNTTABOP_copy UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Grant table operations are expected to return 0 for success, and a negative number for errors. The fix for CVE-2017-12135 / XSA-226 introduced a path through grant copy handling where success may be returned to the caller without any action taken. In particular the status fields of individual operations are left uninitialised, and may result in errant behaviour in the caller of GNTTABOP_copy. IMPACT == A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to copy a grant, it hits the incorrect exit path. This returns success to the caller without doing anything, which may cause in crashes or other incorrect behaviour. VULNERABLE SYSTEMS == Systems running any version of Xen are vulnerable. MITIGATION == Only guests with access to transitive grants can exploit the vulnerability. In particular, this means that: * ARM systems which have taken the XSA-268 fix are not vulnerable, as Grant Table v2 was disabled for other security reasons. * All systems with the XSA-226 fixes, and booted with `gnttab=max-ver:1` or `gnttab=no-transitive` are not vulnerable. CREDITS === This issue was discovered by Pawel Wieczorkiewicz of Amazon and Jürgen Groß of SUSE. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa318.patch Xen 4.9 - xen-unstable $ sha256sum xsa318* 4618c2609ab08178977c2b2a3d13f380ccfddd0168caca5ced708dd76a8e547c xsa318.patch $ NOTE CONCERNING SHORT EMBARGO = This issue was discovered in response to the XSA-316 predisclosure. DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. However, deployment of the mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because it is a guest visible change which will draw attention to the issue. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl6Vpd4MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZbC8IAIkpehqymi1+zrWN1OHdvIYIMv2TCzSSx3UtsoMk J67FpgDzX8ZLfiE0x5FELs3KUdILOe5IkEmM2ssrvQRoIp+X3U4Ybm6eoIB+BzjD bmJReqNYVY6dlJuAhO2i6L125uBITWdntlK/ZOOQAOd77hR2KueuGELV7KUoPbQa SAiQ8jsCjqWCacYll6oq1c7jRlc1+RD/5JjkGveHlLmLOnIiS96PkDzqskM8Aniz TLZ4WmIpfixDAHn3OYyHGoUyhNW3qlps3evDyj3Wela62LFsymDSHkcV8XFBLTGT pueuSELzne5m85moAB2UqKVhHDV+PRCV7bLHYm/s7yeIHSg= =hix9 -END PGP SIGNATURE- xsa318.patch Description: Binary data
Xen Security Advisory 316 v3 (CVE-2020-11743) - Bad error path in GNTTABOP_map_grant
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-11743 / XSA-316 version 3 Bad error path in GNTTABOP_map_grant UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Grant table operations are expected to return 0 for success, and a negative number for errors. Some misplaced brackets cause one error path to return 1 instead of a negative value. The grant table code in Linux treats this condition as success, and proceeds with incorrectly initialised state. IMPACT == A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to map a grant, it hits the incorrect error path. This will crash a Linux based dom0 or backend domain. VULNERABLE SYSTEMS == Systems running any version of Xen with the XSA-295 fixes are vulnerable. Systems which have not yet taken the XSA-295 fixes are not vulnerable. Systems running a Linux based dom0 or driver domain are vulnerable. Systems running a FreeBSD or NetBSD based dom0 or driver domain are not impacted, as they both treat any nonzero value as a failure. The vulnerability of other systems will depend on how they behave when getting an unexpected positive number from the GNTTABOP_map_grant hypercall. MITIGATION == Applying the Linux patches alone is sufficient to mitigate the issue. This might be a preferred route for downstreams who support livepatching Linux but not Xen. CREDITS === This issue was discovered by Ross Lagerwall of Citrix. RESOLUTION == Applying the appropriate Xen patch will resolve this issue. Additionally, a Linux patch is provided to make Linux's behaviour more robust to unexpected values. We recommend taking both patches if at all possible. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa316/xsa316-xen.patch Xen 4.9 - xen-unstable xsa316/xsa316-linux.patch Linux $ sha256sum xsa316*/* 7dcd02e8cc0434046747d572bc6c77cd3a2e4041eefd2fa703f4130e998b58dd xsa316/xsa316-linux.patch 4007578e30730861750d8808c0b63f2e03bbb05df909d71de19201084816a8b9 xsa316/xsa316-xen.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl6Vpd0MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZjOgH/1xKsvqDnR04knl9OWvgL690gqxZpwliRRDwwkWh 1kOHJq2jsvm5bq38fYY9WpvmtvHW/RoM53Kacyz1Rl0y9VvK6hDU7P5np4WkMueX iEJOcIbQau1Pg8/zD8hYkqNNGTCjb79ZhggTih1HxpeZJTa7TJv9bNsZpCQkw+P/ EBXpfsqoPqAMN1qt5PclCT5zlasyBUVjW6+lF3tF6q77knQoWNpKbIOSqL2/V2/p vUMP/qyUikWW8JLH8N48jpRmFzjxwoDI4/3E1sbSv2VxlX1FksbZxan1cwcjoSG6 004GYSxqOjP4oPEAOrC6sXxc6DKoLLa8SVzYNhkg3XoScY0= =qCJA -END PGP SIGNATURE- xsa316/xsa316-linux.patch Description: Binary data xsa316/xsa316-xen.patch Description: Binary data
[Xen-devel] Xen Security Advisory 315 v1 (CVE-2020-0551) - Load Value Injection (LVI) speculative side channel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-0551 / XSA-315 Load Value Injection (LVI) speculative side channel ISSUE DESCRIPTION = This is very closely related to the Microarchitectural Data Sampling vulnerabilities from May 2019. Please see https://xenbits.xen.org/xsa/advisory-297.html for details about MDS. A new way of using the micro-architectural details behind MDS has been identified. Instead of simply trying to sample data from a different privilege context, an attacker can arrange for poisoned data to be consumed (speculatively) in a victim context. This expands the range of tools by which an attacker can manipulate speculation in the victim context to leak data via a side channel. For more details, see: https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection IMPACT == An attacker, which could include a malicious untrusted user process on a trusted guest, or an untrusted guest, can potentially cause a victim context (process, or guest, or guest kernel, or hypervisor) to leak secrets available to it. VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not believed to be vulnerable. Only Intel based processors are potentially affected. Processors from other manufacturers (e.g. AMD) are not believed to be vulnerable. Please consult the Intel Security Advisory for details on the affected processors. MITIGATION == Xen does not support the use of SGX (Software Guard Extensions). Outside of the SGX enclave case, the attacker has a limited ability to control the paging behaviour in the victim context. Therefore, it is not believed that there is a practical way to attack a victim context which is not an SGX enclave. Furthermore, preexisting work (including fixes for MDS, SMAP hardening for user pointers) and in-progress work (core scheduling for SMT systems) all raise the bar further for an attacker. There are no known LVI gadgets within Xen. As a result, we have decided not to make any changes to default configurations of Xen. Systems with untrusted PV guests, and whose host administrators are worried about potential LVI gadgets, might wish to consider changing the VM to be HVM instead, or make use of PV-Shim, to limit the scope of a potential attack. NOTE REGARDING PAGE MODIFICATION LOGGING Included for completeness, rather than due to being a realistic concern: On Intel Broadwell and later systems, Xen uses Page Modification Logging to accelerate logdirty tracking on migration. The use of this does put the guest kernel at a higher risk of being attacked, due to the use of EPT Access/Dirty bits used behind the scenes. Userspace shouldn't be able to influence when a migration occurs, but booting Xen with `ept=no-ad` will mitigate this concern by causing Xen to fall back to software logdirty tracking. RESOLUTION == There is no complete resolution available. In general, administrators of Xen systems are recommended to take no action in response to this vulnerability. If potential LVI gadgets are discovered in Xen, they will be addressed on a case by case basis, in the same way as Spectre v1 hardening. NOTE REGARDING LACK OF EMBARGO == Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl5nyAsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZposH/0ZH/AXAFND2aBRdxKoWZtWyAaxrI0NPRz/H+AEZ CKtoV7E0HmwCSucxJOCe95yv/shKYSqoG4mMkxT+6v1gH7Hv/2dbl12G0Nlo5lyq LSkbvyLwCa1ceL6xa5qanx0GkJL+tiOP3EPDBKpO5Lqok5WS/uXQRwIequArPLNi S4xmE0oKv/yOXRRe2BhnAp6+lY/U6kuMxVNEXF5/6p3/31tnZhabkLJp5N2yl5Ts OEVjwnzEYRgi5npes1TW6PkPA5p0L4rq/oiVPvTqJsNWRkCmHvR2uRXDc1cI/9gs wnam4wTVF2tOXZ8/+n+XvUVUPeLAqzncv2D8+RWkX8pKu18= =DFQP -END PGP SIGNATURE- _______ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Xen Security Advisory 332 v3 - Rogue guests can cause DoS of Dom0 via high frequency events
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-332 version 3 Rogue guests can cause DoS of Dom0 via high frequency events UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The handling of Xen events in the Linux kernel runs with interrupts disabled in a loop until no further event is pending. Whenever an event has been accepted by the kernel, another event can come in via the same event channel. This can result in the event handling loop running for an extended time if new events are coming in at a high rate. In extreme cases this can lead to a complete hang of the kernel, resulting in a DoS situation of the host when dom0 is affected. IMPACT == Malicious guests can hang the host by sending events to dom0 at a high frequency. VULNERABLE SYSTEMS == All systems with a Linux dom0 are affected. All Linux kernel versions are affected. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Julien Grall from Arm RESOLUTION == Applying the appropriate attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa332-linux-??.patch Linux $ sha256sum xsa332* 92d0789e8e5b9ec7ae0cd8b01ef31e27930dbe9b81b727521d46328107f3c719 xsa332-linux-01.patch 0bd82febcaf7fc72b88082f46cae9b67f39786d03b3e6aae5f0789cf855e6143 xsa332-linux-02.patch e646b7caf11ded7f22b209635b209f50ac583cbaeb3270148ce66a3cd922f0c1 xsa332-linux-03.patch 9bed2213774a8107a2f2c157aeb0ebfda7cc6384cee0a245017b3a9eb28cff7f xsa332-linux-04.patch 8839af506b71946db35f223ff614aa92b4386aaf95e4d8b1408fbf31436ff80f xsa332-linux-05.patch b261706bd7f7120fadff0e928be366924cfc13418c81a67ad45724b4179e8a5c xsa332-linux-06.patch fc0c963a9a965fc7a72468b1a1ce0834dc866e77392ca0c1d9c8162457a526a0 xsa332-linux-07.patch 5d821c58dd7fcdb157c2844ba34675305c320de25f54409305ffcba610d5922b xsa332-linux-08.patch 242eb83eca8e3b6d2d303e2943aa041b5f19ea54242cd0de20252d2ae3d128d1 xsa332-linux-09.patch 70a042006d1df3dbbefc4c7d4dfd50da8f3a8e47ee77c2d6d0ba1eda405ae574 xsa332-linux-10.patch ebbfa66d11b8c81353b72ed5f381672e6784a67895df482f7e791a9fb4c6fbf0 xsa332-linux-11.patch cda1cbcca19860d43804e80ec2d7d13b295a140b42aa7d16118bb2d20bd63cae xsa332-linux-12.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl+OzqQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ3MIIAJR5SsBiZM7dhNHSJWMv1OXZK9MBpIxUgJuLY6da dlpsb6c5eb7ppAfHzkg+JABzc1hIKQkzKBL9n/tvP57KAWqnCbrPfk3/pVrvAf9E Vubra4+Ec8hY+8JqJsxHS6ZPyLzViFaE505pBEHlFOGZYkSgqM/s96SgoZtgMSpx pUpFGJCAUPZ7uR+urznM4QrWvvytsRbZo3fUrqn0f9WgMXFge0U9vE7Clt1yzZns J5nmYq2gBJkrMINreth8T7oDCx7l+I+Cq4yJ0hreUWCxp6svl7kbjI55sdlrI99O J7rXH6uaGEHSFfy/Zx4aek3eB5LP6Asgp2pQZkXOcSg8RLE= =q2XX -END PGP SIGNATURE- xsa332-linux-01.patch Description: Binary data xsa332-linux-02.patch Description: Binary data xsa332-linux-03.patch Description: Binary data xsa332-linux-04.patch Description: Binary data xsa332-linux-05.patch Description: Binary data xsa332-linux-06.patch Description: Binary data xsa332-linux-07.patch Description: Binary data xsa332-linux-08.patch Description: Binary data xsa332-linux-09.patch Description: Binary data xsa332-linux-10.patch Description: Binary data xsa332-linux-11.patch Description: Binary data xsa332-linux-12.patch Description: Binary data
Xen Security Advisory 345 v3 - x86: Race condition in Xen mapping code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-345 version 3 x86: Race condition in Xen mapping code UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The Xen code handling the updating of the hypervisor's own pagetables tries to use 2MiB and 1GiB superpages as much as possible to maximize TLB efficiency. Some of the operations for checking and coalescing superpages take non-negligible amount of time; to avoid potential lock contention, this code also tries to avoid holding locks for the entire operation. Unfortunately, several potential race conditions were not considered; precisely-timed guest actions could potentially lead to the code writing to a page which has been freed (and thus potentially already reused). IMPACT == A malicious guest can cause a host denial-of-service. Data corruption or privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == Versions of Xen from at least 3.2 onward are affected. Only x86 systems are vulnerable. ARM systems are not vulnerable. Guests can only exercise the vulnerability if they have passed through hardware devices. Guests without passthrough configured cannot exploit the vulnerability. Furthermore, HVM and PVH guests can only exercise the vulnerability if they are running in shadow mode, and only when running on VT-x capable hardware (as opposed to SVM). This is believed to be Intel, Centaur and Shanghai CPUs. MITIGATION == Running all guests in HVM or PVH mode, in each case with HAP enabled, prevent those guests from exploiting the vulnerability. CREDITS === This issue was discovered by Hongyan Xia of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa345/*.patch xen-unstable xsa345-4.14/*.patch Xen 4.14.x xsa345-4.13/*.patch Xen 4.12.x, Xen 4.13.x xsa345-4.11/*.patch Xen 4.11.x xsa345-4.10/*.patch Xen 4.10.x $ sha256sum xsa345* xsa345*/* c8b9445b05aa4c585d9817c2e6cbf08466452a15381ca5b9a0224a377522edf9 xsa345.meta 4ed69dce620449bedda29f3ce1ed767908d2bbeb888701e7c4c2461216b724f7 xsa345-4.10/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 98d3b171b197c1ff9f26ff70499a0cde3b23d048d622b12bf2ea0899de4f9e7f xsa345-4.10/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 78c4be2f1747051d13869001180ee25bdeabe5e8138d0604a33db610b24e38f1 xsa345-4.10/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 4abd8271a70593fcde683071fdf0ac342ff9b0859b60c9790b14dd7e5ae85129 xsa345-4.11/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 3209195c1a7e8a6186b704d6bb791a3fb3c251d59e15b42bcb0ecc0d38f13a4f xsa345-4.11/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 7e73f6c14718a0d4b25b4453b45c20bf265bd54c91b77678815be1ef7beae61f xsa345-4.11/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch b68b82911c96feee9d05abcddf174c2f6b278829bc8c3bf3062739de8c4704b2 xsa345-4.12/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch fe2a1568a3e273ae01b3984c193e75aea16da53c6c9db27d21a2196d0f204c6e xsa345-4.12/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 22c98f4a264bc6b15ed29da8698a733947849c16a3e9da58de88bf16986b6aad xsa345-4.12/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 16299d885c19e1cd378a856caf8c1d1365c341bea648c0a0d5f24ae7d56015ae xsa345-4.13/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch b820061c242c7fa4da44cbb44fa16e0d0542c16815a89699385da0c87321f7ea xsa345-4.13/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 8a87ac2478c9bda6ef28c480b256448d51393a5e04f6e8a68ea29d9aeba92e47 xsa345-4.13/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch acf093741fecce0018d4a5c0f5dba367373dd1d6d04ed76ff3f178579670 xsa345-4.14/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 616f2547b4bb6d5eb9f853b1659e6e2a1fc0f6785f4f6cdd8d763effcdfc xsa345-4.14/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 17ae72d2af6759da17ce777e0fc9eef8f8eb6be3fe6d5b38b3589f641fc0f918 xsa345-4.14/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 65c56cb4d34ff4e97220311b303c09b54bfa44bcf4adc8e81d4a50c50eeb6b95 xsa345/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 5512bd167c29ba7da06b2ace1397fc43ed33a362174ea927d6ca3f9bdd31748b xsa345/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 392524c9b0a01618e6c86a39dc1c68288065300b49548e29e9e6672947858060 xsa345/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch $ DEPLO
Xen Security Advisory 331 v2 - Race condition in Linux event handler may crash dom0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-331 version 2 Race condition in Linux event handler may crash dom0 UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The Linux kernel event channel handling code doesn't defend the handling of an event against the same event channel being removed in parallel. This can result in accesses to already freed memory areas or NULL pointer dereferences in the event handling code, leading to misbehaviour of the system or even crashes. IMPACT == A misbehaving guest can trigger a dom0 crash by sending events for a paravirtualized device while simultaneously reconfiguring it. VULNERABLE SYSTEMS == All systems with a Linux dom0 are vulnerable. All Linux kernel versions are vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Jinoh Kang of Theori. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa331-linux.patch Linux $ sha256sum xsa331* 8583392c0c573f7baa85e41c9afbdf74dcb04aea1be992d78991f0787230a193 xsa331-linux.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl+OzqMMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZuo4H/R4b4Z7ZTMwwpL4u3PrguNZduaTc3vy9R+Gd0+5z hY0Zfif7SfhJ2apN4Ihs1eAGxyWLI/I8kQQGE4xKgZy2ygciMbTK0OCsoGxfEr6v bi4RKV9I03g3fQHy48z+lOt4XKTY8+OpHw8LYY3W7jdnQ0YJrPCOmap0Xkv91QhP +EkmxzahVQv0T16cP4fxZFUvY0M9gijEjE9h9Gv23M+tLP9SGkW9Hd11qM135AKh vVSYUIuvyd20zb5uiqXono9qP1CeKyCOXHL+YQ+K7eOjYCVbEDdREneBegFlS9By jaFukH/psQDdemQDT4amzOmtBzdImIzkGhflvj+b5axRlrw= =FLDG -END PGP SIGNATURE- xsa331-linux.patch Description: Binary data
Xen Security Advisory 347 v2 - unsafe AMD IOMMU page table updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-347 version 2 unsafe AMD IOMMU page table updates UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = AMD IOMMU page table entries are updated in a step by step manner, without regard to them being potentially in use by the IOMMU. Therefore it was possible that the IOMMU would read and then use a half-updated entry. Furthermore, updates to Device Table entries lacked suitable ordering enforcement for certain steps involved in these updates. In both case the specific outcome heavily depends on how exactly the compiler translated the affected pieces of code. IMPACT == A malicious guest might be able to cause data corruption and data leaks. Host or guest Denial of Service (DoS), and privilege escalation, cannot be ruled out. VULNERABLE SYSTEMS == All Xen versions are potentially vulnerable. Only x86 systems with AMD, Hygon, or compatible IOMMU hardware are vulnerable. Arm systems as well as x86 systems with VT-d hardware or without any IOMMUs in use are not vulnerable. Only x86 guests which have physical devices passed through to them can leverage the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. CREDITS === This issue was discovered by Paul Durrant of Amazon and Jan Beulich of SUSE. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa347/xsa347-?.patch xen-unstable xsa347/xsa347-4.14-?.patch Xen 4.14 xsa347/xsa347-4.13-?.patch Xen 4.13 xsa347/xsa347-4.12-?.patch Xen 4.12 xsa347/xsa347-4.11-?.patch Xen 4.10 - 4.11 $ sha256sum xsa347* xsa347*/* f16e1a348b0e45601c96b2bd08afc4202bbccc92c8af8344b3c8286ca819acef xsa347.meta 82e14d0507ec94f8cfac2b4d5d1b60681b925218ab927332bee338e6b6c679c9 xsa347/xsa347-1.patch 1bc6018c3685727ba4035bf0b5cea95940a1b9c4746fa9bddfd41507482d68a1 xsa347/xsa347-2.patch f1bd8eba268300f564837ac37fe43b774ace885c9cbf8fcacae457128730bc80 xsa347/xsa347-3.patch 5aec8f3b15aa799e1ff7ec0dfe53523cb91aa5fd88033f7f034cb74ebaa6abe4 xsa347/xsa347-4.11-1.patch 4ab3a6fa181ce486b4c9943f6629b7c1a4337c7ccb92701ae6e40108533778ca xsa347/xsa347-4.11-2.patch fec82340dc65fc1001358de51d0639b2b401818fa1e831f8715cb1780b17dc7b xsa347/xsa347-4.12-1.patch be89e976fe03464ce3a73b162c07927128f41a8a03466e903ebfa4ea0dc46116 xsa347/xsa347-4.12-2.patch 5dc0abf73d1a9d21f2b57e6c57ee5c15cc3febbb783123c0946f3e5778671929 xsa347/xsa347-4.13-1.patch 6d2b6ea7a373fb1c4cce63db349bbafa8603b5e7c6b74fc6d029954075f2268d xsa347/xsa347-4.13-2.patch 4e154bfca5101569c8260e307eb6439783bc99547b7dfb5aba2bafebbde46190 xsa347/xsa347-4.13-3.patch 6a70c2afba0d3ad73b12743a6808ba8002e9ee573d7c460397355e40de3b553f xsa347/xsa347-4.14-1.patch 1bc6018c3685727ba4035bf0b5cea95940a1b9c4746fa9bddfd41507482d68a1 xsa347/xsa347-4.14-2.patch f1bd8eba268300f564837ac37fe43b774ace885c9cbf8fcacae457128730bc80 xsa347/xsa347-4.14-3.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because removal of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl+Ozq4MHHBncEB4ZW4u b
Xen Security Advisory 346 v2 - undue deferral of IOMMU TLB flushes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-346 version 2 undue deferral of IOMMU TLB flushes UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = To efficiently change the physical to machine address mappings of a larger range of addresses for fully virtualized guests, Xen contains an optimization to coalesce per-page IOMMU TLB flushes into a single, wider flush after all adjustments have been made. While this is fine to do for newly introduced page mappings, the possible removal of pages from such guests during this operation should not be "optimized" in the same way. This is because the (typically) final reference of such pages is dropped before the coalesced flush, and hence the pages may have been put to a different use even though DMA initiated by their original owner mightstill be in progress. IMPACT == A malicious guest might be able to cause data corruption and data leaks. Host or guest Denial of Service (DoS), and privilege escalation, cannot be ruled out. VULNERABLE SYSTEMS ====== All Xen versions from 4.2 onwards are vulnerable. Xen versions 4.1 and earlier are not vulnerable. Only x86 HVM and PVH guests can leverage the vulnerability. Arm guests as well as x86 PV ones cannot leverage the vulnerability. Only x86 HVM and PVH guests which have physical devices passed through to them can leverage the vulnerability. Only x86 HVM and PVH guests configured to not share IOMMU and CPU page tables can leverage the vulnerability. Sharing these page tables is the default on capable Intel (VT-d) hardware. On AMD hardware sharing is not possible. On Intel (VT-d) hardware sharing may also not be possible, depending on hardware properties. Whether it is possible can be seen from the presence (or absence) of "iommu_hap_pt_share" on the "virt_caps" line of "xl info" output. Guests run in shadow mode can leverage the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. On systems permitting page table sharing, not suppressing use of the functionality will allow to avoid the vulnerability. This means guests should not be run in * shadow mode, i.e. hardware needs to be HAP (Hardware Assisted Paging) capable, there should not be "hap=0" in the guest's xl configuration file, and there should not be "hap=0" or equivalent on Xen's command line, * non-shared page table mode, i.e. hardware needs to be capable of sharing, there should not be "passthrough=sync_pt" in the guest's xl configuration file, and there should not be "iommu=no-sharept" or equivalent on Xen's command line. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate pair of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa346/xsa346-?.patch Xen 4.14 - xen-unstable xsa346/xsa346-4.13-?.patch Xen 4.13 xsa346/xsa346-4.12-?.patch Xen 4.12 xsa346/xsa346-4.11-?.patch Xen 4.11 xsa346/xsa346-4.10-?.patch Xen 4.10 $ sha256sum xsa346* xsa346*/* ba560d34cb46f45d6da0ba5d672cb896c173e90de5c022d22415ace20c5e47b8 xsa346.meta 5f8b3e5565bc7d87283af173f5f2b35975e4ab6bff502780799d14fb263f730d xsa346/xsa346-1.patch 9de89ca360f303e7aa3b42529cdf4191b0700ee7cb6928a22068195e047a4db7 xsa346/xsa346-2.patch f3612bfad219160917a3bc46ea5b31673137593d62ae4f819a8e80ade0339c5b xsa346/xsa346-4.10-1.patch 734ed82d583bbce342ffabeb9dd84e300f2717ec71e3de866670b0ddf18d57aa xsa346/xsa346-4.10-2.patch 7a41bf06e19590cfc69d4f2ac132a23843dcec2ea5f98d86c4be971f9eec86af xsa346/xsa346-4.11-1.patch 1359801b8f64ac62dc8de4e3acc15ec42c040f692f3a1ee9986acb478ee330cd xsa346/xsa346-4.11-2.patch 190f594bb77dd044af8f0a051ab1d4143c348da192206da9b390af91c0a2cdec xsa346/xsa346-4.12-1.patch 5bcb65dc45f6d74c644ee6b6add518044c9875e6759254773d3816e718c2be28 xsa346/xsa346-4.12-2.patch 69e0158276a922829eb60dc5bb13e60a71a232ace808843f45dac407716b107b xsa346/xsa346-4.13-1.patch eb8132a02c252dc65be1f334939f252db0c30ae2db8aa23f0d9e67f8148e2d2d xsa346/xsa346-4.13-2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen P
Xen Security Advisory 286 v5 - x86 PV guest INVLPG-like flushes may leave stale TLB entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-286 version 5 x86 PV guest INVLPG-like flushes may leave stale TLB entries UPDATES IN VERSION 5 Patches rewritten to use a completely different approach. The patches supplied in XSA-286 version 4 were found to have a significant performance impact. An alternative approach was developed and has now been committed to the relevant Xen branches. The alternative approach is simpler and mitigates the performance problems. At the time of writing the patches in XSA-286 v4 are believed to be correct and sound, but if we discover that this is not the case we will not issue a further update. We recommend the use of the patches provided in the Xen git branches, which are the same as those attached in this version of the advisory. ISSUE DESCRIPTION = x86 PV guest kernels may use hypercalls with INVLPG-like behavior to invalidate TLB entries even after changes to non-leaf page tables. Such changes to non-leaf page tables will, however, also render stale possible TLB entries created by Xen's internal use of linear page tables to process guest requests like update-va-mapping. Invalidation of these TLB entries has been missing, allowing subsequent guest requests to change address mappings for one process to potentially modify memory meanwhile in use elsewhere. IMPACT == Malicious x86 PV guest user mode may be able to escalate their privilege to that of the guest kernel. VULNERABLE SYSTEMS == All versions of Xen expose the vulnerability. The vulnerability is exposed to x86 PV guests only. x86 HVM/PVH guests as well as ARM ones are not vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. xsa286-unstable/*.patch xen-unstable xsa286-4.14/*.patch Xen 4.14.x xsa286-4.13/*.patch Xen 4.13.x xsa286-4.12/*.patch Xen 4.12.x xsa286-4.11/*.patch Xen 4.11.x xsa286-4.10/*.patch Xen 4.10.x $ sha256sum xsa286* xsa286*/* a7d4ddb15197dfcb246b84f8a89799f76070cdde99a5c1d0203229d719b0fcc1 xsa286.meta e5f946b07989db85de2a03e4b88e09324316c0ec12d21c5afb83d463114a1f4f xsa286-unstable/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch 2a732c958201eb03cc0737278e75f86160e0dedbbe0a13f415ec0d17a90ec009 xsa286-unstable/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch 2da4b60e19b1fbf1daf0d1bc61733763abf5653a6e53ffeadd559d0a01ec8095 xsa286-4.10/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch 5ce7f56a9b2c9a3a63f79d7df2486c24fc130a8658deb182b22416e17c202ae9 xsa286-4.10/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch 2e700e091bfd9d3fd6dd65064ec39a8a40d73bcc94b66852fd2d6fbe9ba6c2db xsa286-4.11/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch d622652ce50d59bf45134baabc26b89a24e5d98b1f82230041919089a1cf1620 xsa286-4.11/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch 4dc18a007ddf2bd5022ce194b861989be88170f8188ce49dbea7073bb280202f xsa286-4.12/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch 2c48331849d4d401b47dfc3db84bb067786b4e53155587235d919781b4a10e76 xsa286-4.12/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch dd0fad5165dcd0c3d8d551e35fa4fe29653a3b8c5ec52f7f86f434305c946338 xsa286-4.13/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch de1326efd4a8559c32ac68c89095f3230f723dec2acc80fc01a534578bb1be82 xsa286-4.13/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch a718f5e19ce821d1fe06f2cdc2f7ad0bbe7c7bca954c283bbc36ad50522f66ef xsa286-4.14/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch d659d4a4119b235c7d1054980ceea9424dcc7faf3cfd3fd46627577a424256b5 xsa286-4.14/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproje
Xen Security Advisory 351 v1 - Information leak via power sidechannel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-351 Information leak via power sidechannel ISSUE DESCRIPTION = Researchers have demonstrated using software power/energy monitoring interfaces to create covert channels, and infer the operations/data used by other contexts within the system. Access to these interfaces should be restricted to privileged software, but it was found that Xen doesn't restrict access suitably, and the interfaces are accessible to all guests. For more information, see: https://platypusattack.com https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html IMPACT == An unprivileged guest administrator can sample platform power/energy data. This may be used to infer the operations/data used by other contexts within the system. The research demonstrates using this sidechannel to leak the AES keys used elsewhere in the system. VULNERABLE SYSTEMS == Power/energy monitoring interfaces are platform and architecture specific. Consult your hardware vendor to ascertain what power feedback interfaces are available. For ARM systems, all versions of Xen are vulnerable. The fix restricts access to the AMU (Activity Monitors Unit) interface, introduced in Armv8.4. For x86 systems, Xen 4.14 and earlier are vulnerable - master is not vulnerable, as these issues have been addressed in a more general fashion. The x86 fixes restrict access to: * Intel RAPL interface, introduced in SandyBridge CPUs. * Intel platform energy interface. * Intel perf_ctl interface, introduced in Pentium 4 CPUs and also implemented by other vendors. * AMD RAPL interface, introduced in Ryzen/EPYC CPUs. * AMD compute unit energy interface, present in Fam15/16 CPUs. MITIGATION == There are no mitigations available. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa351-arm.patch Xen unstable - 4.10.x [ARM] xsa351-x86-4.14-?.patch Xen 4.14.x[x86] xsa351-x86-4.13-?.patch Xen 4.13.x[x86] xsa351-x86-4.12-?.patch Xen 4.12.x[x86] xsa351-x86-4.11-?.patch Xen 4.11.x - 4.10.x [x86] $ sha256sum xsa351* cad287981a870f13484834fa2364ffee68178517e906f55d2889304a4a9eae06 xsa351.meta 70ebd0e93af240af2680374dcfd8ff4a5dd3eefccf670f1cb9b546d763d6a554 xsa351-arm.patch 49b52a1366912a29e184e3014a9f1f579e8a0dd8a36f01d38d995d2c8ed81928 xsa351-arm-4.11.patch 2e7b7c2b98625d70c8b10047a9f668372f3ccede167344dedb712312606acbca xsa351-x86-4.11-1.patch ab9e2cb7d5e3e0c3a916f006c697495f4f01146e09df60ece59ce0a8f7aa5ed0 xsa351-x86-4.11-2.patch bb68f6e6905bc1566156cafab058cbaf02a17c197385c33a83b7f73885913c1c xsa351-x86-4.12-1.patch 53f464269f59498f8a9a614f10a47cfb1d81c666f0d684346e28005015de962c xsa351-x86-4.12-2.patch 67a29d66230faafd9a8047ac80ec18130b5659e80a38c3a412cb2be6d3288a8f xsa351-x86-4.13-1.patch f7d8717dec33ee7484b36490402d113f1e7e168e7541bcf193fef620df299f08 xsa351-x86-4.13-2.patch 7d4fbe11a766226d7f1b93c5bf34664d8855deee09d1feebc76f11e49f2aa9c9 xsa351-x86-4.14-1.patch 41df825deafe3ef28e8594ec956033689af69f84a4a6dd92f97d1071e925203d xsa351-x86-4.14-2.patch $ NOTE REGARDING LACK OF EMBARGO == Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl+q1WwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZANkH+wf8pft4t9KoC9HFxd96DfCjZ+FQnD0hMp+890cY ztNJM4+o+SBP2ytEMZLIoN1oJeTSQqyNgQh2sXNm7/WpseklOTR6s8zw4LWATEfz rqF8G2xIN8ka7AAqAwOzkzj6qlxuWbiXKm4ENd5ocRxVvF1A2PYyEX88uCPgmupg dqfufhYQF7hrz8VKDRDYtLsMrRaIFCWqGdOdQfVF64pHGHLvGZkANGN8yva8mBfC uavwvX+O3CdVMENS4AA3TNo6p2nnWp1iQJCiBwLGCRbTQaRtRucV4Q/eSLC3pHLp NO26OxieT4tLJN7Ox4ex43KZIsyweZSaUl18rfg0J8MB3FM= =/6Fo -END PGP SIGNATURE- xsa351.meta Description: Binary data xsa351-arm.patch Description: Binary data xsa351-arm-4.11.patch Description: Binary data xsa351-x86-4.11-1.patch Description: Binary data xsa351-x86-4.11-2.patch Description: Binary data xsa351-x86-4.12-1.patch Description: Binary data xsa351-x86-4.12-2.patch Description: Binary data xsa351-x86-4.13-1.patch Description: Binary data xsa351-x86-4.13-2.patch Description: Binary data xsa351-x86-4.14-1.patch Description: Binary data xsa351-x86-4.14-2.patch Description: Binary data
Xen Security Advisory 351 v1 - Information leak via power sidechannel
(Copy of advisory) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-351 Information leak via power sidechannel ISSUE DESCRIPTION = Researchers have demonstrated using software power/energy monitoring interfaces to create covert channels, and infer the operations/data used by other contexts within the system. Access to these interfaces should be restricted to privileged software, but it was found that Xen doesn't restrict access suitably, and the interfaces are accessible to all guests. For more information, see: https://platypusattack.com https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html IMPACT == An unprivileged guest administrator can sample platform power/energy data. This may be used to infer the operations/data used by other contexts within the system. The research demonstrates using this sidechannel to leak the AES keys used elsewhere in the system. VULNERABLE SYSTEMS == Power/energy monitoring interfaces are platform and architecture specific. Consult your hardware vendor to ascertain what power feedback interfaces are available. For ARM systems, all versions of Xen are vulnerable. The fix restricts access to the AMU (Activity Monitors Unit) interface, introduced in Armv8.4. For x86 systems, Xen 4.14 and earlier are vulnerable - master is not vulnerable, as these issues have been addressed in a more general fashion. The x86 fixes restrict access to: * Intel RAPL interface, introduced in SandyBridge CPUs. * Intel platform energy interface. * Intel perf_ctl interface, introduced in Pentium 4 CPUs and also implemented by other vendors. * AMD RAPL interface, introduced in Ryzen/EPYC CPUs. * AMD compute unit energy interface, present in Fam15/16 CPUs. MITIGATION == There are no mitigations available. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa351-arm.patch Xen unstable - 4.10.x [ARM] xsa351-x86-4.14-?.patch Xen 4.14.x[x86] xsa351-x86-4.13-?.patch Xen 4.13.x[x86] xsa351-x86-4.12-?.patch Xen 4.12.x[x86] xsa351-x86-4.11-?.patch Xen 4.11.x - 4.10.x [x86] $ sha256sum xsa351* cad287981a870f13484834fa2364ffee68178517e906f55d2889304a4a9eae06 xsa351.meta 70ebd0e93af240af2680374dcfd8ff4a5dd3eefccf670f1cb9b546d763d6a554 xsa351-arm.patch 49b52a1366912a29e184e3014a9f1f579e8a0dd8a36f01d38d995d2c8ed81928 xsa351-arm-4.11.patch 2e7b7c2b98625d70c8b10047a9f668372f3ccede167344dedb712312606acbca xsa351-x86-4.11-1.patch ab9e2cb7d5e3e0c3a916f006c697495f4f01146e09df60ece59ce0a8f7aa5ed0 xsa351-x86-4.11-2.patch bb68f6e6905bc1566156cafab058cbaf02a17c197385c33a83b7f73885913c1c xsa351-x86-4.12-1.patch 53f464269f59498f8a9a614f10a47cfb1d81c666f0d684346e28005015de962c xsa351-x86-4.12-2.patch 67a29d66230faafd9a8047ac80ec18130b5659e80a38c3a412cb2be6d3288a8f xsa351-x86-4.13-1.patch f7d8717dec33ee7484b36490402d113f1e7e168e7541bcf193fef620df299f08 xsa351-x86-4.13-2.patch 7d4fbe11a766226d7f1b93c5bf34664d8855deee09d1feebc76f11e49f2aa9c9 xsa351-x86-4.14-1.patch 41df825deafe3ef28e8594ec956033689af69f84a4a6dd92f97d1071e925203d xsa351-x86-4.14-2.patch $ NOTE REGARDING LACK OF EMBARGO == Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl+q1WwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZANkH+wf8pft4t9KoC9HFxd96DfCjZ+FQnD0hMp+890cY ztNJM4+o+SBP2ytEMZLIoN1oJeTSQqyNgQh2sXNm7/WpseklOTR6s8zw4LWATEfz rqF8G2xIN8ka7AAqAwOzkzj6qlxuWbiXKm4ENd5ocRxVvF1A2PYyEX88uCPgmupg dqfufhYQF7hrz8VKDRDYtLsMrRaIFCWqGdOdQfVF64pHGHLvGZkANGN8yva8mBfC uavwvX+O3CdVMENS4AA3TNo6p2nnWp1iQJCiBwLGCRbTQaRtRucV4Q/eSLC3pHLp NO26OxieT4tLJN7Ox4ex43KZIsyweZSaUl18rfg0J8MB3FM= =/6Fo -END PGP SIGNATURE- xsa351.meta Description: Binary data xsa351-arm.patch Description: Binary data xsa351-arm-4.11.patch Description: Binary data xsa351-x86-4.11-1.patch Description: Binary data xsa351-x86-4.11-2.patch Description: Binary data xsa351-x86-4.12-1.patch Description: Binary data xsa351-x86-4.12-2.patch Description: Binary data xsa351-x86-4.13-1.patch Description: Binary data xsa351-x86-4.13-2.patch Description: Binary data xsa351-x86-4.14-1.patch Description: Binary data xsa351-x86-4.14-2.patch Description: Binary data
Xen Security Advisory 355 v2 - stack corruption from XSA-346 change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-355 version 2 stack corruption from XSA-346 change UPDATES IN VERSION 2 Added metadata file. Public release. ISSUE DESCRIPTION = One of the two changes for XSA-346 introduced an on-stack array. The check for guarding against overrunning this array was off by one, allowing for corruption of the first stack slot immediately following this array. IMPACT == A malicious or buggy HVM or PVH guest can cause Xen to crash, resulting in a Denial of Service (DoS) to the entire host. Privilege escalation as well as information leaks cannot be excluded. VULNERABLE SYSTEMS == All Xen versions which have the patches for XSA-346 applied are vulnerable. Only x86 HVM and PVH guests can leverage the vulnerability. Arm guests and x86 PV guests cannot leverage the vulnerability. Only x86 HVM and PVH guests which have physical devices passed through to them can leverage the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa355.patch xen-unstable - Xen 4.10.x $ sha256sum xsa355* a93bfc376897e7cffd095d395f1a66476adb9503d7d80a59b7861e64c2675323 xsa355.meta dae633c11cf2eff3e304737265e18ab09213e8e4640458080a944ae7a40819a4 xsa355.patch $ NOTE CONCERNING SHORT EMBARGO = This issue is likely to be re-discovered as the changes for XSA-346 are deployed more widely, since the issue is also triggerable without any malice or bugginess. DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl+89pEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZRHQH/1D8CfjZWYgLcdYOg6sDO6BIK8IsnAiOoe2C8b9i M8QPFzHlUx09FI5CHVb0Va/pFliR1OS2tmmIU30DL9nmiDLcaP2uvpgJAYo5GwL5 Rzccjo4qbXwfSRQvHmLzbr+XN8sHDxbekpFd8T5WvuarUgxOaPCLTfSG0nag/t52 OVNIdDcP5lSt/Z88lYW75j4gBAsXUZDEXgn81JpeHj9js8YLFC3WFcwh58Jjd+hw 5DH955jNAKD8TRSy6uffDpvN1m9wm2vDGeXSUcJyswlV8Nqi6YRW4XO4Q6Cfj+CG LVBS/T977JZGJjRvTw4j0H+xAXiLFwQ1I/6v6fSZzxDMt9k= =+4M1 -END PGP SIGNATURE- xsa355.meta Description: Binary data xsa355.patch Description: Binary data
[Xen-devel] Xen Security Advisory 312 v1 - arm: a CPU may speculate past the ERET instruction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-312 arm: a CPU may speculate past the ERET instruction ISSUE DESCRIPTION = Some CPUs can speculate past an ERET instruction and potentially perform speculative accesses to memory before processing the exception return. Since the register state is often controlled by lower privilege level (i.e guest kernel/userspace) at the point of the ERET, this could potentially be used as part of a side-channel attack. IMPACT == An attacker, which could include a malicious untrusted user process on a trusted guest, or an untrusted guest, may be able to use it as part of side-channel attack to read host memory. VULNERABLE SYSTEMS == System running all version of Xen are affected. Whether an individual Arm-based CPU is vulnerable depends on its speculation properties. Consult your CPU vendor. x86 systems are not vulnerable. MITIGATION == There is no mitigation available. NOTE REGARDING LACK OF EMBARGO == This was reported publicly, as affecting other Open Source projects, before the Xen Project Security Team was made aware. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa312.patch xen-unstable, Xen 4.13 - 4.12 xsa312-4.11.patch Xen 4.11 - 4.10 xsa312-4.9.patch Xen 4.9 $ sha256sum xsa312* 112c9d77f964174db5709c758626a2bd5fec9bfdacc89fbc96f1ddd44aca6bbf xsa312.meta 9b2078d448e4815c9ddc6554bf869d64412dc787b1b94830a24e47df6a9f30e7 xsa312.patch 29b95d6ea0295e124c3cfd5b1611ae341bb195d1c441ee69976e2f74cde652a8 xsa312-4.9.patch 8d64b3039c570f4b5c82abbbcf2714ec3b60db55fe3e1b3bb838df7dfaf627e9 xsa312-4.11.patch $ -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl4dzjAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZOx4H/2nt+377yBhbqNqUO2nCbqUWBkCB/OHQQ3uyjytp PEDW9epevCJHOvQ3w24gh9SplWupHvrzS2PbqCWwEMPZXfkYB6Ye2kr7hbJHMOxB bP6qm71plWG/RGmKSTVeVbOqAtiwdXkIvE8PIETGSuQ3Ip8exIkWvXnkY3v7KQne WIg+vcadAqvv9oZj8UAv+V6oihUr1MyOMaddsW0QczF1yhs7EErpSBrLT1G2+nm/ MxY8nE40rAzZBs+G1puODC8uK/LSmGlvms+200FOPHnyyIKmznmAtGLE7pziPj7F Qdy4GOWLAE1oQcrglmdk6SOCK7CRJSSZ0RminYNNPSX6EqM= =FnmX -END PGP SIGNATURE- xsa312.meta Description: Binary data xsa312.patch Description: Binary data xsa312-4.9.patch Description: Binary data xsa312-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Xen Security Advisory 331 v3 (CVE-2020-27675) - Race condition in Linux event handler may crash dom0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-27675 / XSA-331 version 3 Race condition in Linux event handler may crash dom0 UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The Linux kernel event channel handling code doesn't defend the handling of an event against the same event channel being removed in parallel. This can result in accesses to already freed memory areas or NULL pointer dereferences in the event handling code, leading to misbehaviour of the system or even crashes. IMPACT == A misbehaving guest can trigger a dom0 crash by sending events for a paravirtualized device while simultaneously reconfiguring it. VULNERABLE SYSTEMS == All systems with a Linux dom0 are vulnerable. All Linux kernel versions are vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Jinoh Kang of Theori. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa331-linux.patch Linux $ sha256sum xsa331* 8583392c0c573f7baa85e41c9afbdf74dcb04aea1be992d78991f0787230a193 xsa331-linux.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAHB6QMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZDpEH/1DgvbcVJRbGyzc8TA80oAT+zeVQpTaZkgGthQV/ PvJQH/sMi5mrgQ7pkTVu08wY4/BWTzz+0bceD/+PqMoXBYn+56y3oavVUdAsrK6P Bjucd+TI0kOrRx/82FlVtjir8xPZuiBi1xHxb4mQRc70BqJfI9GETOnFsGYhFpcX woDuHAfum3+6fUFyRPhyu7MoWChfyOQxu6IxU22rpelT1wAOPsIi15fX0Xbz3nJi 7bIbc3Hv9EAv114RsDZbNhz8ymzj5BL/gXWQO13187NGVhDlKdi91zdDQqbKTKTW 4Hvl/6zARGLEPxh6oQbQhxhnMHD5+BVPvacarjNjtHdkJTk= =pzTm -END PGP SIGNATURE- xsa331-linux.patch Description: Binary data
Xen Security Advisory 355 v3 (CVE-2020-29040) - stack corruption from XSA-346 change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-29040 / XSA-355 version 3 stack corruption from XSA-346 change UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = One of the two changes for XSA-346 introduced an on-stack array. The check for guarding against overrunning this array was off by one, allowing for corruption of the first stack slot immediately following this array. IMPACT == A malicious or buggy HVM or PVH guest can cause Xen to crash, resulting in a Denial of Service (DoS) to the entire host. Privilege escalation as well as information leaks cannot be excluded. VULNERABLE SYSTEMS == All Xen versions which have the patches for XSA-346 applied are vulnerable. Only x86 HVM and PVH guests can leverage the vulnerability. Arm guests and x86 PV guests cannot leverage the vulnerability. Only x86 HVM and PVH guests which have physical devices passed through to them can leverage the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa355.patch xen-unstable - Xen 4.10.x $ sha256sum xsa355* a93bfc376897e7cffd095d395f1a66476adb9503d7d80a59b7861e64c2675323 xsa355.meta dae633c11cf2eff3e304737265e18ab09213e8e4640458080a944ae7a40819a4 xsa355.patch $ NOTE CONCERNING SHORT EMBARGO = This issue is likely to be re-discovered as the changes for XSA-346 are deployed more widely, since the issue is also triggerable without any malice or bugginess. DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAHB6UMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZpMAH/AwWuyJ0tQS95kJmfCSe9gxFkIZwnoOlxAIF1fQ8 0W7OXmgrr9giz3lVR6Kjannq3HextHuLoVttg3soJ6pCqPBOH84/k0vyHEb9ChBF ypkvH0iG1wnpVo+DdYOnY7OnaBHrPsB0E83WfKohP05e+Ymcroq09vKw02fR6B+z +D3uNzbNi1kZz1DcTZFsCAmHJsc3zS+D8jyEwOFQwlVckugJ+zDuylKtSDau56CN WGG3nkoDldWm1687ui4stnal8WIBP6sMgErwnv9hpzfL5glc/m0PSELQ8hZgNmAX KMoWvdjPenwPQEhrii92P15DbXGz6uktIZFrKRgCUx2u5ss= =1hd2 -END PGP SIGNATURE- xsa355.meta Description: Binary data xsa355.patch Description: Binary data
Xen Security Advisory 286 v6 (CVE-2020-27674) - x86 PV guest INVLPG-like flushes may leave stale TLB entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-27674 / XSA-286 version 6 x86 PV guest INVLPG-like flushes may leave stale TLB entries UPDATES IN VERSION 6 CVE assigned. ISSUE DESCRIPTION = x86 PV guest kernels may use hypercalls with INVLPG-like behavior to invalidate TLB entries even after changes to non-leaf page tables. Such changes to non-leaf page tables will, however, also render stale possible TLB entries created by Xen's internal use of linear page tables to process guest requests like update-va-mapping. Invalidation of these TLB entries has been missing, allowing subsequent guest requests to change address mappings for one process to potentially modify memory meanwhile in use elsewhere. IMPACT == Malicious x86 PV guest user mode may be able to escalate their privilege to that of the guest kernel. VULNERABLE SYSTEMS == All versions of Xen expose the vulnerability. The vulnerability is exposed to x86 PV guests only. x86 HVM/PVH guests as well as ARM ones are not vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. xsa286-unstable/*.patch xen-unstable xsa286-4.14/*.patch Xen 4.14.x xsa286-4.13/*.patch Xen 4.13.x xsa286-4.12/*.patch Xen 4.12.x xsa286-4.11/*.patch Xen 4.11.x xsa286-4.10/*.patch Xen 4.10.x $ sha256sum xsa286* xsa286*/* a7d4ddb15197dfcb246b84f8a89799f76070cdde99a5c1d0203229d719b0fcc1 xsa286.meta e5f946b07989db85de2a03e4b88e09324316c0ec12d21c5afb83d463114a1f4f xsa286-unstable/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch 2a732c958201eb03cc0737278e75f86160e0dedbbe0a13f415ec0d17a90ec009 xsa286-unstable/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch 2da4b60e19b1fbf1daf0d1bc61733763abf5653a6e53ffeadd559d0a01ec8095 xsa286-4.10/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch 5ce7f56a9b2c9a3a63f79d7df2486c24fc130a8658deb182b22416e17c202ae9 xsa286-4.10/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch 2e700e091bfd9d3fd6dd65064ec39a8a40d73bcc94b66852fd2d6fbe9ba6c2db xsa286-4.11/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch d622652ce50d59bf45134baabc26b89a24e5d98b1f82230041919089a1cf1620 xsa286-4.11/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch 4dc18a007ddf2bd5022ce194b861989be88170f8188ce49dbea7073bb280202f xsa286-4.12/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch 2c48331849d4d401b47dfc3db84bb067786b4e53155587235d919781b4a10e76 xsa286-4.12/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch dd0fad5165dcd0c3d8d551e35fa4fe29653a3b8c5ec52f7f86f434305c946338 xsa286-4.13/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch de1326efd4a8559c32ac68c89095f3230f723dec2acc80fc01a534578bb1be82 xsa286-4.13/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch a718f5e19ce821d1fe06f2cdc2f7ad0bbe7c7bca954c283bbc36ad50522f66ef xsa286-4.14/0001-x86-pv-Drop-FLUSH_TLB_GLOBAL-in-do_mmu_update-for-XP.patch d659d4a4119b235c7d1054980ceea9424dcc7faf3cfd3fd46627577a424256b5 xsa286-4.14/0002-x86-pv-Flush-TLB-in-response-to-paging-structure-cha.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAHB6MMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZDi4IAL8YKoMnrvTD8nNVHvUyTgVRpO9w68qq5r8gG3Z6 InBZWYOp+YrMScoqFap+R1RylIcKtzlqbCn3TR0dZdKDviPMpbgIQwEHI7C7I+qM rN4/cmEljAY+dspU2isqzX6IEDSwk4H9NcUtzN7+MbpUrJiis597IxW5T0KMM5Bd FYd2/MmzEayZkcEtuMLcFKdl2n1mi+7x7jNlQW5FeHI+6F8SS76YlYs2d/iaDC98 cX4YMdo4ZzcXpKVXgppbga7AEC1AZaNIfBd5cFrZaCvDBYnmW4Zwz8W7R/wYO987 5ogHMu0GX92i8QwN5EBwLolhnruZIBnaSJ9PiGk0GRbgGw4= =AADk -END PGP SIGNATURE- xsa286.meta Description: Binary data xsa286-unstable/0001-x86-pv-Drop-FLUS
Xen Security Advisory 332 v4 (CVE-2020-27673) - Rogue guests can cause DoS of Dom0 via high frequency events
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-27673 / XSA-332 version 4 Rogue guests can cause DoS of Dom0 via high frequency events UPDATES IN VERSION 4 CVE assigned. ISSUE DESCRIPTION = The handling of Xen events in the Linux kernel runs with interrupts disabled in a loop until no further event is pending. Whenever an event has been accepted by the kernel, another event can come in via the same event channel. This can result in the event handling loop running for an extended time if new events are coming in at a high rate. In extreme cases this can lead to a complete hang of the kernel, resulting in a DoS situation of the host when dom0 is affected. IMPACT == Malicious guests can hang the host by sending events to dom0 at a high frequency. VULNERABLE SYSTEMS == All systems with a Linux dom0 are affected. All Linux kernel versions are affected. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Julien Grall from Arm RESOLUTION == Applying the appropriate attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa332-linux-??.patch Linux $ sha256sum xsa332* 92d0789e8e5b9ec7ae0cd8b01ef31e27930dbe9b81b727521d46328107f3c719 xsa332-linux-01.patch 0bd82febcaf7fc72b88082f46cae9b67f39786d03b3e6aae5f0789cf855e6143 xsa332-linux-02.patch e646b7caf11ded7f22b209635b209f50ac583cbaeb3270148ce66a3cd922f0c1 xsa332-linux-03.patch 9bed2213774a8107a2f2c157aeb0ebfda7cc6384cee0a245017b3a9eb28cff7f xsa332-linux-04.patch 8839af506b71946db35f223ff614aa92b4386aaf95e4d8b1408fbf31436ff80f xsa332-linux-05.patch b261706bd7f7120fadff0e928be366924cfc13418c81a67ad45724b4179e8a5c xsa332-linux-06.patch fc0c963a9a965fc7a72468b1a1ce0834dc866e77392ca0c1d9c8162457a526a0 xsa332-linux-07.patch 5d821c58dd7fcdb157c2844ba34675305c320de25f54409305ffcba610d5922b xsa332-linux-08.patch 242eb83eca8e3b6d2d303e2943aa041b5f19ea54242cd0de20252d2ae3d128d1 xsa332-linux-09.patch 70a042006d1df3dbbefc4c7d4dfd50da8f3a8e47ee77c2d6d0ba1eda405ae574 xsa332-linux-10.patch ebbfa66d11b8c81353b72ed5f381672e6784a67895df482f7e791a9fb4c6fbf0 xsa332-linux-11.patch cda1cbcca19860d43804e80ec2d7d13b295a140b42aa7d16118bb2d20bd63cae xsa332-linux-12.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAHB6QMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZbAwIAIDvNzGNP3XXzGzMbI3yiEBTzixf3W/75IqO8sHA fFGJVPv9GEk2miB9NbwX/3opX1LXOlX+l4Uq+Zh+LnVO3tOYFwpzNaL+ji6D0BCp Pi1i8B1MRhvHITcmoB76I9bZYWnAOKwMSoPIYWVInh5STFSosERmccvFAA5ar7Rw aJYcs9Cuxt/8cJTpETD9nvm1m7vmXuqcj7szAd0DSVmaJwidHwTiIr4Qs1pVSk3K RqPeHkjfg7/KRhQkpwwZbELDVRRylo5oEL9RklBwUPyiS297EFLFJut6w5rmycbS vTK7w7Sby5Z2hv6oUn+2w6Y62LzHWZIFp5fwbvO5x6EdGRc= =/68h -END PGP SIGNATURE- xsa332-linux-01.patch Description: Binary data xsa332-linux-02.patch Description: Binary data xsa332-linux-03.patch Description: Binary data xsa332-linux-04.patch Description: Binary data xsa332-linux-05.patch Description: Binary data xsa332-linux-06.patch Description: Binary data xsa332-linux-07.patch Description: Binary data xsa332-linux-08.patch Description: Binary data xsa332-linux-09.patch Description: Binary data xsa332-linux-10.patch Description: Binary data xsa332-linux-11.patch Description: Binary data xsa332-linux-12.patch Description: Binary data
Xen Security Advisory 347 v3 (CVE-2020-27670) - unsafe AMD IOMMU page table updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-27670 / XSA-347 version 3 unsafe AMD IOMMU page table updates UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = AMD IOMMU page table entries are updated in a step by step manner, without regard to them being potentially in use by the IOMMU. Therefore it was possible that the IOMMU would read and then use a half-updated entry. Furthermore, updates to Device Table entries lacked suitable ordering enforcement for certain steps involved in these updates. In both case the specific outcome heavily depends on how exactly the compiler translated the affected pieces of code. IMPACT == A malicious guest might be able to cause data corruption and data leaks. Host or guest Denial of Service (DoS), and privilege escalation, cannot be ruled out. VULNERABLE SYSTEMS == All Xen versions are potentially vulnerable. Only x86 systems with AMD, Hygon, or compatible IOMMU hardware are vulnerable. Arm systems as well as x86 systems with VT-d hardware or without any IOMMUs in use are not vulnerable. Only x86 guests which have physical devices passed through to them can leverage the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. CREDITS === This issue was discovered by Paul Durrant of Amazon and Jan Beulich of SUSE. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa347/xsa347-?.patch xen-unstable xsa347/xsa347-4.14-?.patch Xen 4.14 xsa347/xsa347-4.13-?.patch Xen 4.13 xsa347/xsa347-4.12-?.patch Xen 4.12 xsa347/xsa347-4.11-?.patch Xen 4.10 - 4.11 $ sha256sum xsa347* xsa347*/* f16e1a348b0e45601c96b2bd08afc4202bbccc92c8af8344b3c8286ca819acef xsa347.meta 82e14d0507ec94f8cfac2b4d5d1b60681b925218ab927332bee338e6b6c679c9 xsa347/xsa347-1.patch 1bc6018c3685727ba4035bf0b5cea95940a1b9c4746fa9bddfd41507482d68a1 xsa347/xsa347-2.patch f1bd8eba268300f564837ac37fe43b774ace885c9cbf8fcacae457128730bc80 xsa347/xsa347-3.patch 5aec8f3b15aa799e1ff7ec0dfe53523cb91aa5fd88033f7f034cb74ebaa6abe4 xsa347/xsa347-4.11-1.patch 4ab3a6fa181ce486b4c9943f6629b7c1a4337c7ccb92701ae6e40108533778ca xsa347/xsa347-4.11-2.patch fec82340dc65fc1001358de51d0639b2b401818fa1e831f8715cb1780b17dc7b xsa347/xsa347-4.12-1.patch be89e976fe03464ce3a73b162c07927128f41a8a03466e903ebfa4ea0dc46116 xsa347/xsa347-4.12-2.patch 5dc0abf73d1a9d21f2b57e6c57ee5c15cc3febbb783123c0946f3e5778671929 xsa347/xsa347-4.13-1.patch 6d2b6ea7a373fb1c4cce63db349bbafa8603b5e7c6b74fc6d029954075f2268d xsa347/xsa347-4.13-2.patch 4e154bfca5101569c8260e307eb6439783bc99547b7dfb5aba2bafebbde46190 xsa347/xsa347-4.13-3.patch 6a70c2afba0d3ad73b12743a6808ba8002e9ee573d7c460397355e40de3b553f xsa347/xsa347-4.14-1.patch 1bc6018c3685727ba4035bf0b5cea95940a1b9c4746fa9bddfd41507482d68a1 xsa347/xsa347-4.14-2.patch f1bd8eba268300f564837ac37fe43b774ace885c9cbf8fcacae457128730bc80 xsa347/xsa347-4.14-3.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because removal of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAHB6UMHHBncEB4ZW4u b
Xen Security Advisory 345 v4 (CVE-2020-27672) - x86: Race condition in Xen mapping code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-27672 / XSA-345 version 4 x86: Race condition in Xen mapping code UPDATES IN VERSION 4 CVE assigned. ISSUE DESCRIPTION = The Xen code handling the updating of the hypervisor's own pagetables tries to use 2MiB and 1GiB superpages as much as possible to maximize TLB efficiency. Some of the operations for checking and coalescing superpages take non-negligible amount of time; to avoid potential lock contention, this code also tries to avoid holding locks for the entire operation. Unfortunately, several potential race conditions were not considered; precisely-timed guest actions could potentially lead to the code writing to a page which has been freed (and thus potentially already reused). IMPACT == A malicious guest can cause a host denial-of-service. Data corruption or privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == Versions of Xen from at least 3.2 onward are affected. Only x86 systems are vulnerable. ARM systems are not vulnerable. Guests can only exercise the vulnerability if they have passed through hardware devices. Guests without passthrough configured cannot exploit the vulnerability. Furthermore, HVM and PVH guests can only exercise the vulnerability if they are running in shadow mode, and only when running on VT-x capable hardware (as opposed to SVM). This is believed to be Intel, Centaur and Shanghai CPUs. MITIGATION == Running all guests in HVM or PVH mode, in each case with HAP enabled, prevent those guests from exploiting the vulnerability. CREDITS === This issue was discovered by Hongyan Xia of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa345/*.patch xen-unstable xsa345-4.14/*.patch Xen 4.14.x xsa345-4.13/*.patch Xen 4.12.x, Xen 4.13.x xsa345-4.11/*.patch Xen 4.11.x xsa345-4.10/*.patch Xen 4.10.x $ sha256sum xsa345* xsa345*/* c8b9445b05aa4c585d9817c2e6cbf08466452a15381ca5b9a0224a377522edf9 xsa345.meta 4ed69dce620449bedda29f3ce1ed767908d2bbeb888701e7c4c2461216b724f7 xsa345-4.10/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 98d3b171b197c1ff9f26ff70499a0cde3b23d048d622b12bf2ea0899de4f9e7f xsa345-4.10/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 78c4be2f1747051d13869001180ee25bdeabe5e8138d0604a33db610b24e38f1 xsa345-4.10/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 4abd8271a70593fcde683071fdf0ac342ff9b0859b60c9790b14dd7e5ae85129 xsa345-4.11/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 3209195c1a7e8a6186b704d6bb791a3fb3c251d59e15b42bcb0ecc0d38f13a4f xsa345-4.11/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 7e73f6c14718a0d4b25b4453b45c20bf265bd54c91b77678815be1ef7beae61f xsa345-4.11/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch b68b82911c96feee9d05abcddf174c2f6b278829bc8c3bf3062739de8c4704b2 xsa345-4.12/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch fe2a1568a3e273ae01b3984c193e75aea16da53c6c9db27d21a2196d0f204c6e xsa345-4.12/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 22c98f4a264bc6b15ed29da8698a733947849c16a3e9da58de88bf16986b6aad xsa345-4.12/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 16299d885c19e1cd378a856caf8c1d1365c341bea648c0a0d5f24ae7d56015ae xsa345-4.13/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch b820061c242c7fa4da44cbb44fa16e0d0542c16815a89699385da0c87321f7ea xsa345-4.13/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 8a87ac2478c9bda6ef28c480b256448d51393a5e04f6e8a68ea29d9aeba92e47 xsa345-4.13/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch acf093741fecce0018d4a5c0f5dba367373dd1d6d04ed76ff3f178579670 xsa345-4.14/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 616f2547b4bb6d5eb9f853b1659e6e2a1fc0f6785f4f6cdd8d763effcdfc xsa345-4.14/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 17ae72d2af6759da17ce777e0fc9eef8f8eb6be3fe6d5b38b3589f641fc0f918 xsa345-4.14/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 65c56cb4d34ff4e97220311b303c09b54bfa44bcf4adc8e81d4a50c50eeb6b95 xsa345/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 5512bd167c29ba7da06b2ace1397fc43ed33a362174ea927d6ca3f9bdd31748b xsa345/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 392524c9b0a01618e6c86a39dc1c68288065300b49548e29e9e6672947858060 xsa345/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.
Xen Security Advisory 346 v3 (CVE-2020-27671) - undue deferral of IOMMU TLB flushes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-27671 / XSA-346 version 3 undue deferral of IOMMU TLB flushes UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = To efficiently change the physical to machine address mappings of a larger range of addresses for fully virtualized guests, Xen contains an optimization to coalesce per-page IOMMU TLB flushes into a single, wider flush after all adjustments have been made. While this is fine to do for newly introduced page mappings, the possible removal of pages from such guests during this operation should not be "optimized" in the same way. This is because the (typically) final reference of such pages is dropped before the coalesced flush, and hence the pages may have been put to a different use even though DMA initiated by their original owner mightstill be in progress. IMPACT == A malicious guest might be able to cause data corruption and data leaks. Host or guest Denial of Service (DoS), and privilege escalation, cannot be ruled out. VULNERABLE SYSTEMS ====== All Xen versions from 4.2 onwards are vulnerable. Xen versions 4.1 and earlier are not vulnerable. Only x86 HVM and PVH guests can leverage the vulnerability. Arm guests as well as x86 PV ones cannot leverage the vulnerability. Only x86 HVM and PVH guests which have physical devices passed through to them can leverage the vulnerability. Only x86 HVM and PVH guests configured to not share IOMMU and CPU page tables can leverage the vulnerability. Sharing these page tables is the default on capable Intel (VT-d) hardware. On AMD hardware sharing is not possible. On Intel (VT-d) hardware sharing may also not be possible, depending on hardware properties. Whether it is possible can be seen from the presence (or absence) of "iommu_hap_pt_share" on the "virt_caps" line of "xl info" output. Guests run in shadow mode can leverage the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. On systems permitting page table sharing, not suppressing use of the functionality will allow to avoid the vulnerability. This means guests should not be run in * shadow mode, i.e. hardware needs to be HAP (Hardware Assisted Paging) capable, there should not be "hap=0" in the guest's xl configuration file, and there should not be "hap=0" or equivalent on Xen's command line, * non-shared page table mode, i.e. hardware needs to be capable of sharing, there should not be "passthrough=sync_pt" in the guest's xl configuration file, and there should not be "iommu=no-sharept" or equivalent on Xen's command line. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate pair of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa346/xsa346-?.patch Xen 4.14 - xen-unstable xsa346/xsa346-4.13-?.patch Xen 4.13 xsa346/xsa346-4.12-?.patch Xen 4.12 xsa346/xsa346-4.11-?.patch Xen 4.11 xsa346/xsa346-4.10-?.patch Xen 4.10 $ sha256sum xsa346* xsa346*/* ba560d34cb46f45d6da0ba5d672cb896c173e90de5c022d22415ace20c5e47b8 xsa346.meta 5f8b3e5565bc7d87283af173f5f2b35975e4ab6bff502780799d14fb263f730d xsa346/xsa346-1.patch 9de89ca360f303e7aa3b42529cdf4191b0700ee7cb6928a22068195e047a4db7 xsa346/xsa346-2.patch f3612bfad219160917a3bc46ea5b31673137593d62ae4f819a8e80ade0339c5b xsa346/xsa346-4.10-1.patch 734ed82d583bbce342ffabeb9dd84e300f2717ec71e3de866670b0ddf18d57aa xsa346/xsa346-4.10-2.patch 7a41bf06e19590cfc69d4f2ac132a23843dcec2ea5f98d86c4be971f9eec86af xsa346/xsa346-4.11-1.patch 1359801b8f64ac62dc8de4e3acc15ec42c040f692f3a1ee9986acb478ee330cd xsa346/xsa346-4.11-2.patch 190f594bb77dd044af8f0a051ab1d4143c348da192206da9b390af91c0a2cdec xsa346/xsa346-4.12-1.patch 5bcb65dc45f6d74c644ee6b6add518044c9875e6759254773d3816e718c2be28 xsa346/xsa346-4.12-2.patch 69e0158276a922829eb60dc5bb13e60a71a232ace808843f45dac407716b107b xsa346/xsa346-4.13-1.patch eb8132a02c252dc65be1f334939f252db0c30ae2db8aa23f0d9e67f8148e2d2d xsa346/xsa346-4.13-2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen P
Xen Security Advisory 360 v1 - IRQ vector leak on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-360 IRQ vector leak on x86 ISSUE DESCRIPTION = A x86 HVM guest with PCI pass through devices can force the allocation of all IDT vectors on the system by rebooting itself with MSI or MSI-X capabilities enabled and entries setup. Such reboots will leak any vectors used by the MSI(-X) entries that the guest might had enabled, and hence will lead to vector exhaustion on the system, not allowing further PCI pass through devices to work properly. IMPACT == HVM guests with PCI pass through devices can mount a Denial of Service (DoS) attack affecting the pass through of PCI devices to other guests or the hardware domain. In the latter case this would affect the entire host. VULNERABLE SYSTEMS == Xen versions 4.12.3, 4.12.4, and all versions from 4.13.1 onwards are vulnerable. Xen version 4.13.0 and all versions up to 4.12.2 are not affected. Only x86 systems running HVM guests with PCI pass through devices are vulnerable. MITIGATION == Not running HVM guests with PCI pass through devices will avoid the vulnerability. Note that even non-malicious guests can trigger this vulnerability as part of normal operation. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa360.patch xen-unstable xsa360-4.14.patch Xen 4.14 - 4.12 $ sha256sum xsa360* c874ad2b9edb0791ac975735306d055b1916f4acbc59e6f1550fbf33223d6106 xsa360.meta 592f3afda63777d31844e0e34d85fbe387a62d59fa7903ee19b22a98fba68894 xsa360.patch 809515011efb781a2a8742e9acfd76412d3920c2d4142bb187588cd36f77383e xsa360-4.14.patch $ CREDITS === This issue was discovered by James McCoy, debugged in combination with Samuel Verschelde of Vates, and recognised as a security issue by Roger Pau Monné of Citrix. NOTE REGARDING LACK OF EMBARGO == This was reported and debugged publicly, before the security implications were apparent. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAJixQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZh4cH/RyA5POGYEJEj4jHUFK+UmT08Bo6igUBMyJSvAJs T81eb35E2E2I8P35L7q8OOuLIGPWnTXOGPRnwizr2YF7UhmMm/773q5ellShUBgm SHtYl+btRaAp6gXB1PhgiETN3EH3aRgn89YBAQmg3U4Zb1RUiB2P2x6pVEGjMfBw Ks3Zj/ElCtfJcBA6xerNNLuqhwamueCEukw5b8eEHnop+y7TuLordpGGMybpQctx m04lp7zuJDAeshf47wlMQps79Ysx72CaThVKe/9A09z/c2mcR3m+NbieP7PJPggr n1I6QEaSUuapszkj+lC/L05tiyHdjXkoNAHwtdPr8jKtbKo= =YdXv -END PGP SIGNATURE- xsa360.meta Description: Binary data xsa360.patch Description: Binary data xsa360-4.14.patch Description: Binary data
Xen Security Advisory 360 v2 (CVE-2021-3308) - IRQ vector leak on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-3308 / XSA-360 version 2 IRQ vector leak on x86 UPDATES IN VERSION 2 CVE assigned. ISSUE DESCRIPTION = An x86 HVM guest with PCI pass through devices can force the allocation of all IDT vectors on the system by rebooting itself with MSI or MSI-X capabilities enabled and entries setup. Such reboots will leak any vectors used by the MSI(-X) entries that the guest might had enabled, and hence will lead to vector exhaustion on the system, not allowing further PCI pass through devices to work properly. IMPACT == HVM guests with PCI pass through devices can mount a Denial of Service (DoS) attack affecting the pass through of PCI devices to other guests or the hardware domain. In the latter case this would affect the entire host. VULNERABLE SYSTEMS == Xen versions 4.12.3, 4.12.4, and all versions from 4.13.1 onwards are vulnerable. Xen version 4.13.0 and all versions up to 4.12.2 are not affected. Only x86 systems running HVM guests with PCI pass through devices are vulnerable. MITIGATION == Not running HVM guests with PCI pass through devices will avoid the vulnerability. Note that even non-malicious guests can trigger this vulnerability as part of normal operation. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa360.patch xen-unstable xsa360-4.14.patch Xen 4.14 - 4.12 $ sha256sum xsa360* c874ad2b9edb0791ac975735306d055b1916f4acbc59e6f1550fbf33223d6106 xsa360.meta 592f3afda63777d31844e0e34d85fbe387a62d59fa7903ee19b22a98fba68894 xsa360.patch 809515011efb781a2a8742e9acfd76412d3920c2d4142bb187588cd36f77383e xsa360-4.14.patch $ CREDITS === This issue was discovered by James McCoy, debugged in combination with Samuel Verschelde of Vates, and recognised as a security issue by Roger Pau Monné of Citrix. NOTE REGARDING LACK OF EMBARGO == This was reported and debugged publicly, before the security implications were apparent. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAQkcMMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZCnkIAL4JBZ19GKWeLyjZSYJxMR7y677B0CQ627Swmu0L UoCk6VhVmwNuqgU12yEiE8fgUA1sx2WIHcc4ZLBSA6RmaWLy21SKpDywNk1bDuGu aAYqzgWg4ESaEt22khvOdqvWYVn7N6Ferg7Xeaf+w8MJo5qwwAqnbn2sO432uWga rSeOBMnmrNsgWkoCNmcTVzFjhxHKz94mReGFGStN96zQuI2DedkKzWHS6YcDydAw qyRmO3D+2RJGwTIAYQqKvT/wBtTLI1uCp2DOYEDS8A8zkMy88k9+1703N/BxfB31 Ax04vEHoJj0EaLV4dyqRaVDcW9iZSpgvMQGB/x2Jp6knrG8= =Dr9U -END PGP SIGNATURE- xsa360.meta Description: Binary data xsa360.patch Description: Binary data xsa360-4.14.patch Description: Binary data
Xen Security Advisory 365 v3 (CVE-2021-26930) - Linux: error handling issues in blkback's grant mapping
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-26930 / XSA-365 version 3 Linux: error handling issues in blkback's grant mapping UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = To service requests, the driver maps grant references provided by the frontend. In this process, errors may be encountered. In one case an error encountered earlier might be discarded by later processing, resulting in the caller assuming successful mapping, and hence subsequent operations trying to access space that wasn't mapped. In another case internal state would be insufficiently updated, preventing safe recovery from the error. IMPACT == A malicious or buggy frontend driver may be able to crash the corresponding backend driver, potentially affecting the entire domain running the backend driver. In configurations without driver domains or similar disaggregation, that is a host-wide denial of sevice. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS == Linux versions from at least 3.11 onwards are vulnerable. MITIGATION == Reconfiguring guests to use alternative (e.g. qemu-based) backends may avoid the vulnerability. CREDITS === This issue was discovered by Olivier Benjamin, Norbert Manthey, Martin Mazein, and Jan H. Schönherr, all from Amazon. RESOLUTION == Applying the attached patch resolves this issue. xsa365-linux.patch Linux 5.11-rc - 5.10 $ sha256sum xsa365* 7e45fcf3c70eb40debe9997a1773de7c4a2edcde5c23f76aeb5c1b6e3a34a654 xsa365-linux.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the non-kernel-based backends mitigation described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change may be recognizable by the affected guests. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAru/UMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZnpQH/jMHOQao08C5s4VlCUIDJTJ8AZXIjFKW2zOKBqt5 Gp7HiRZSLKa2s/dqxIdiVHTnMzGyFegfzK0AeLjLeftSbOANSvI9tx/S6ajOr6Mx s5j0r2JzCBsh1bULJbRV7MBVaRqyOR77i3sREu7o0uuRxMd0RNnck7rVm0slmG1P FoFfC2tF+gxnYZi8tpBS4aY/e3tZ4y+J6s0Fgyfln4p33/j1JwILzzYscGnRdDvG 31DnotOq3E+TqcTZRK4BrLJqZodZLsd9en1DriJj2dDqrobs6QS4sZkHKX20gcxC RnGvkdHXI+u/du6qpb3GHep2F5pg5+2vMzBNvxxBjr8vmi4= =HBCB -END PGP SIGNATURE- xsa365-linux.patch Description: Binary data
Xen Security Advisory 363 v3 (CVE-2021-26934) - Linux: display frontend "be-alloc" mode is unsupported
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-26934 / XSA-363 version 3 Linux: display frontend "be-alloc" mode is unsupported UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The backend allocation mode of Linux'es drm_xen_front drivers was not meant to be a supported configuration, but this wasn't stated accordingly in its support status entry. IMPACT == Use of the feature may have unknown effects. VULNERABLE SYSTEMS == Linux versions from 4.18 onwards are affected. Earlier Linux versions do not provide the affected driver. MITIGATION == Not using the driver or its backend allocation mode will avoid the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch documents the situation. The patch does not fix any security issues. xsa363.patch xen-unstable $ sha256sum xsa363* cf2f2eff446aec625b19d9d01301ec66098b58b792d74012235f10c62a21bb68 xsa363.patch $ -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAru/UMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZSocH/3jAI0MeZtnhvuyOM4CxkNmr0fI4HIXnA1xGNhWY Wa2WgtOuFVaPUFX1Tj/e6zCoibatl1gicETI9hL+w4Dg6/GzIeTogOuzv5D6Ux91 9a6n2tryFfSAs0OxTKq6etLv63VEEicYMHrZT8n700JFvJsAWYAMvuanMDknGxBP 5/Z+DASnZxT09cpvP4REKuG7rW9vIif+6EZ0T0kU87InouDts/YOhzNsdvBD1wKH y5e/MZh2sOyMOovuhgbvoK+YezHTAcZeGWnUk3yQoTGnW3p+W9XZVURsc8/e2FbZ heY3Tj918LsY50wGpMZ2PDoHC8PSHaUqEOTq0MPmnPlppvU= =tJD0 -END PGP SIGNATURE- xsa363.patch Description: Binary data
Xen Security Advisory 364 v3 (CVE-2021-26933) - arm: The cache may not be cleaned for newly allocated scrubbed pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-26933 / XSA-364 version 3 arm: The cache may not be cleaned for newly allocated scrubbed pages UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = On Arm, a guest is allowed to control whether memory access bypass the cache. This means that Xen needs to ensure that all writes (such as the ones during scrubbing) have reached memory before handing over the page to a guest. Unfortunately the operation to clean the cache happens before checking if the page was scrubbed. Therefore there is no guarantee when all the writes will reach the memory. IMPACT == A malicious guest may be able to read sensitive data from memory that previously belonged to another guest. VULNERABLE SYSTEMS == Xen version 4.9 onwards are vulnerable. Only Arm systems are vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Julien Grall of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa364.patch xen-unstable - 4.11 $ sha256sum xsa364* c9dcb3052bb6ca4001e02b3ad889c70b4eebf1931bef83dfb7de86452851f3c8 xsa364.meta dc313c70bb07b4096bbc4612cbbc180589923277411dede2fda37f04ecc846d6 xsa364.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAru/UMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZT0UH/0Lzw4sShqmyO06n0HWcXyzXKx7Qh67tjBglmB0D XHKrlTKR0Cs1S2NR3GCSZCSPNKXcXU689qEXlvK07EpheO/xCUgpZNkt/Eab/JFK NngYbuev1z6+bGeCi70b6RItCXoWiwDWEJqLlLKROwBXMZaodwgjY7/o3GR2D8ZV Qyz2EcAdJUIYmMsLC3hJ7gTLXvdySp+0lZ9oO6qe4YYQ3CIwPJnlflWFTzcASfML D9lMVG6u6ratiqt4N1egE0gxBe3/QP8KoptSqiV+MDdwPnsK009g/G+0Ea430ZEh lviVSgCxhdELx2Tv+Q7qSSbnfMSdnibSHAxipcbyhvjiEJU= =mHyv -END PGP SIGNATURE- xsa364.meta Description: Binary data xsa364.patch Description: Binary data
Xen Security Advisory 361 v4 (CVE-2021-26932) - Linux: grant mapping error handling issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-26932 / XSA-361 version 4 Linux: grant mapping error handling issues UPDATES IN VERSION 4 Public release. ISSUE DESCRIPTION = Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. IMPACT == A malicious or buggy frontend driver may be able to crash the corresponding backend driver, causing a denial of service potentially affecting the entire domain running the backend driver. A malicious or buggy frontend driver may be able to cause resource leaks in the domain running the corresponding backend driver, leading to a denial of service. VULNERABLE SYSTEMS == All Linux versions back to at least 3.2 are vulnerable, when running in PV mode on x86 or when running on Arm. On x86, only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. MITIGATION == On x86, running the backends in HVM or PVH domains will avoid the vulnerability. For protocols where other, e.g. non-kernel-based backends are available, reconfiguring guests to use alternative (e.g. qemu-based) backends may allow to avoid the vulnerability as long as these backends don't rely on similar functionality provided by the xen-gntdev (/dev/gntdev) driver. In all other cases there is no known mitigation. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patches resolves this issue. xsa361-linux-1.patch Linux 5.11-rc - 3.19 xsa361-linux-2.patch Linux 5.11-rc - 3.15 xsa361-linux-3.patch Linux 5.11-rc - 4.19 xsa361-linux-4.patch Linux 5.11-rc - 4.19 xsa361-linux-5.patch Linux 5.11-rc - 4.4 $ sha256sum xsa361* bb00ab6319b4fc536566af50c73e064f10f8b99eaa6b0f0b35a8d174c285a905 xsa361-linux-1.patch 73b6a54aa3773ce11f0de6b9aa1d80dd7f4c297dc71924b1a3886bc3b99ac859 xsa361-linux-2.patch 8e554cfab8cdb4fe1b74601a9432ea4c570f74a952ad757f9294ba1666cbeaea xsa361-linux-3.patch 8c290895d10fc148f99e2a6587811b3037f29c3a0201d69d448ff520cea6f96d xsa361-linux-4.patch 231ae3e1b9bec1b75dbbbee4b5acff620ef7ac2853332aa7b3c4957c6ca7f341 xsa361-linux-5.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. Deployment of the mitigation to switch to HVM / PVH backend domains is also permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the non-kernel-based backends mitigation described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change may be recognizable by the affected guests. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAru/QMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZmFkH/Ay1RoZbbcA4ywdhy9xdnpt0DHMFLjZSbE4sNTi+ J+m9rn69UTK01VDD0RUohTcmWO0nv8ZD+jKETsSq31GiYhVk7XnSmCJkzILGujr8 cf+7jUWWJPcqBmN7xcLBaor9lhpKfMpYlMLBG7twIRHfqOSw6Sm+iD4YC23nkGKF Cb8tpkYCpX3dPMMP74nX00Wta2rqd1BrpAGvAnt9hrHIBfTcpwWE8A4H1eFL/7Dv 5+pVvrSMkyzaR5kI/QBeriXsuOP509CiafUBpeXU85pGWpLgZAqD+puodEVQ2fpT /MqATdNRhgnCzqSqh/ElN/1ZdB7406DbdCnErJiyDdN/OCE= =DUXr -END PGP SIGNATURE- xsa361-linux-1.patch Description: Binary data xsa361-linux-2.patch Description: Binary data xsa36
Xen Security Advisory 362 v3 (CVE-2021-26931) - Linux: backends treating grant mapping errors as bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-26931 / XSA-362 version 3 Linux: backends treating grant mapping errors as bugs UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Block, net, and SCSI backends consider certain errors a plain bug, deliberately causing a kernel crash. For errors potentially being at least under the influence of guests, like out of memory conditions, it isn't correct to assume so. Memory allocations potentially causing such crashes occur only when Linux is running in PV mode, though. IMPACT == A malicious or buggy frontend driver may be able to crash the corresponding backend driver, potentially affecting the entire domain running the backend driver. VULNERABLE SYSTEMS == Linux versions from at least 2.6.39 onwards are vulnerable, when run in PV mode. Earlier versions differ significantly in behavior and may therefore instead surface other issues under the same conditions. Linux run in HVM / PVH modes is not vulnerable. MITIGATION == For Linux, running the backends in HVM or PVH domains will avoid the vulnerability. For protocols where non-Linux-kernel based backends are available, reconfiguring guests to use alternative (e.g. qemu-based) backends may allow to avoid the vulnerability. In all other cases there is no known mitigation. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patches resolves this issue. Applying the attached patches resolves this issue. xsa362-linux-1.patch Linux 5.11-rc - 5.10 xsa362-linux-2.patch Linux 5.11-rc - 3.16 xsa362-linux-3.patch Linux 5.11-rc - 4.1 $ sha256sum xsa362* d64334807f16ff9909503b3cc9b8b93fd42d2c36e1fb0e508b89a765a53071a8 xsa362-linux-1.patch b6d02952e7fbede55b868cb2dc4d8853284996883dc72518a0cd5b14d6c7fdd4 xsa362-linux-2.patch 0a2661380d8f786fefe12e5a8b1528d4a79f1ad058c26b417c52449a7e16a302 xsa362-linux-3.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. Deployment of the mitigation to switch to HVM / PVH backend domains is also permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the non-kernel-based backends mitigation described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change may be recognizable by the affected guests. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAru/UMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZszQH/jwCgehGBbejtpFjiOqEPdqIQhd0X+Q1feFD9PB6 07gfGanmSds5mitr0ezTHbfLw85CoFbAJhalNdx9XeQrZTIvRAizkCi779rE9UYZ H0CN73GoObF4E8q+tVRpZni0Rcnb77bETRsmlYjRYRjtZNZ1+7vbn4tf4JMccoo0 qhz1/bqY3e4yHPcdxb9P3T/DQKNG+nJjkn4kNueYo1PUGUetxw6HXbXWHh6WvbOr mfd+sTxRSf+Nk2OZhtofjIYEIeL058axZoSuARBIPphBmOCumUTGzrypZwe5BTuF GMQqlguxPU0rFscGd/Js05suFhQQR4ccJlSGRs7pswt9i0M= =KnG3 -END PGP SIGNATURE- xsa362-linux-1.patch Description: Binary data xsa362-linux-2.patch Description: Binary data xsa362-linux-3.patch Description: Binary data
Xen Security Advisory 366 v1 - missed flush in XSA-321 backport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-366 missed flush in XSA-321 backport ISSUE DESCRIPTION = An oversight was made when backporting XSA-320, leading entries in the IOMMU not being properly updated under certain circumstances. IMPACT == A malicious guest may be able to retain read/write DMA access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes (leading to a Denial of Service) and privilege escalation cannot be ruled out. VULNERABLE SYSTEMS ====== Xen versions up to 4.11, from at least 3.2 onwards, are affected. Xen versions 4.12 and newer are not affected. Only x86 Intel systems are affected. x86 AMD as well as Arm systems are not affected. Only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device assigned, and having page table sharing enabled can leverage the vulnerability. Note that page table sharing will be enabled (by default) only if Xen considers IOMMU and CPU large page size support compatible. MITIGATION == Suppressing the use of page table sharing will avoid the vulnerability (command line option "iommu=no-sharept"). Suppressing the use of large HAP pages will avoid the vulnerability (command line options "hap_2mb=no hap_1gb=no"). Not passing through PCI devices to HVM guests will avoid the vulnerability. CREDITS === This issue was reported as a bug by M. Vefa Bicakci, and recognized as a security issue by Roger Pau Monne of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa366-4.11.patch Xen 4.11.x $ sha256sum xsa366* 3131c9487b9446655e2e21df4ccf1e003bec471881396d7b2b1a0939f5cbae96 xsa366.meta 8c8c18ca8425e6167535c3cf774ffeb9dcb4572e81c8d2ff4a73fefede2d4d94 xsa366-4.11.patch $ NOTE REGARDING LACK OF EMBARGO == This was reported and debugged publicly, before the security implications were apparent. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAuU5EMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZMCkIAKq1dU6xOMN3lFqY6LeIV+Pn+JQDvJKhDT+lJT9b KAP+a44ks5bHHSD6CPyiq5boU5APE7yqiyJnXBycXVDLH6GGjh7uBvc6A00YkeHU y08l8jxa6/FAyrvCj5P0pYItALwH0NZDtfUE57ueloYUu3KJnyBRtl9icvx/sCa9 CUkpKDpS0te+Rk+G57UPDjGvSPwpIh01vphJ5tyf+2Lrk8rsHTJYWQ7eD8A09jCr DtSD6FylzEuGGY30vPGLUzXgOm8Nji/WgnXnmmbILCEo8PQs3CcoxN53/F8cYvr6 NRERHKZFhHoLmUUCImoFcApxzzdt11USDnCdEXiAkrEOYsk= =w9OA -END PGP SIGNATURE- xsa366.meta Description: Binary data xsa366-4.11.patch Description: Binary data
Xen Security Advisory 366 v2 (CVE-2021-27379) - missed flush in XSA-321 backport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-27379 / XSA-366 version 2 missed flush in XSA-321 backport UPDATES IN VERSION 2 CVE assigned. Fixed erroneous reference to XSA-320; should have read XSA-321. ISSUE DESCRIPTION = An oversight was made when backporting XSA-321, leading entries in the IOMMU not being properly updated under certain circumstances. IMPACT == A malicious guest may be able to retain read/write DMA access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes (leading to a Denial of Service) and privilege escalation cannot be ruled out. VULNERABLE SYSTEMS ====== Xen versions up to 4.11, from at least 3.2 onwards, are affected. Xen versions 4.12 and newer are not affected. Only x86 Intel systems are affected. x86 AMD as well as Arm systems are not affected. Only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device assigned, and having page table sharing enabled can leverage the vulnerability. Note that page table sharing will be enabled (by default) only if Xen considers IOMMU and CPU large page size support compatible. MITIGATION == Suppressing the use of page table sharing will avoid the vulnerability (command line option "iommu=no-sharept"). Suppressing the use of large HAP pages will avoid the vulnerability (command line options "hap_2mb=no hap_1gb=no"). Not passing through PCI devices to HVM guests will avoid the vulnerability. CREDITS === This issue was reported as a bug by M. Vefa Bicakci, and recognized as a security issue by Roger Pau Monne of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa366-4.11.patch Xen 4.11.x $ sha256sum xsa366* 3131c9487b9446655e2e21df4ccf1e003bec471881396d7b2b1a0939f5cbae96 xsa366.meta 8c8c18ca8425e6167535c3cf774ffeb9dcb4572e81c8d2ff4a73fefede2d4d94 xsa366-4.11.patch $ NOTE REGARDING LACK OF EMBARGO == This was reported and debugged publicly, before the security implications were apparent. -BEGIN PGP SIGNATURE- iQE/BAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmA1Lx4MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZXRkH+MsCFrh/HOCaqzbdlT46sZBSS3B7wMjaCt4WtB8z MKxRY013/MMi7xbOhMvLE/qEtT8cdkOykxac9WjMnAPk2NQE3L3uRvoWsS8cYLa6 39RklCw0o/0YTsiY4bB5X1jI+8dBZxt4QPYl1YQqsLOHTlSJFix2Vm6w/K8+BZt9 ceS58GEoAawwlkVXdSH2115rSVRoBUZqgHCkPIc6eOjAmXCPL++8uUToWWhiROWD Ic0STLsf/Rt44G71rPh8GoFdncIBULcPlp1LbxCUEzRVhdmeb1/shs79vsIk0Z3l c2oHzypyS15p/kdQbulGTXDFq933C4ELtjrY/HwPumJSdg== =er6n -END PGP SIGNATURE- xsa366.meta Description: Binary data xsa366-4.11.patch Description: Binary data
Xen Security Advisory 329 v2 - Linux ioperm bitmap context switching issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-329 version 2 Linux ioperm bitmap context switching issues UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Linux 5.5 overhauled the internal state handling for the iopl() and ioperm() system calls. Unfortunately, one aspect on context switch wasn't wired up correctly for the Xen PVOps case. IMPACT == IO port permissions don't get rescinded when context switching to an unprivileged task. Therefore, all userspace can use the IO ports granted to the most recently scheduled task with IO port permissions. VULNERABLE SYSTEMS == Only x86 guests are vulnerable. All versions of Linux from 5.5 are potentially vulnerable. Linux is only vulnerable when running as x86 PV guest. Linux is not vulnerable when running as an x86 HVM/PVH guests. The vulnerability can only be exploited in domains which have been granted access to IO ports by Xen. This is typically only the hardware domain, and guests configured with PCI Passthrough. MITIGATION == Running only HVM/PVH guests avoids the vulnerability. CREDITS === This issue was discovered by Andy Lutomirski. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa329.patch Linux 5.5 and later $ sha256sum xsa329* cdb5ac9bfd21192b5965e8ec0a1c4fcf12d0a94a962a8158cd27810e6aa362f0 xsa329.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl8QU6EMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ/sEIAMiCOnz119KTlRU50HTwa4pvIgLphf9htTbPzHXS iEb8yINqMxmep8NRcAzwFREQP+Z4Tue1upt31Vx0RPkFZpUklLuuBSXsV0JA7+UM LSGyWhkzDdnfj6iPUHycGmFzRTzkbB7qfcMj7khCvuYtSNbTUdOgUq04ngZksrSJ UMhfgUNKXawULKvVe7572L/AQTmMXK8eaolb+eWtf1U2pFkZQR8GWoLmiFbKLks2 X2tRUF4U4cHEBzxXRzYrD1ArWLajqK6hQmauwgkCCSowvCHoD1dTv55GlrlEo4od MSB6YOVLl7HJuUw1GmwlKjA8XqStHq1Fi0urvlKCfHfK2Wk= =MP+m -END PGP SIGNATURE- xsa329.patch Description: Binary data
Xen Security Advisory 329 v3 (CVE-2020-15852) - Linux ioperm bitmap context switching issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-15852 / XSA-329 version 3 Linux ioperm bitmap context switching issues UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Linux 5.5 overhauled the internal state handling for the iopl() and ioperm() system calls. Unfortunately, one aspect on context switch wasn't wired up correctly for the Xen PVOps case. IMPACT == IO port permissions don't get rescinded when context switching to an unprivileged task. Therefore, all userspace can use the IO ports granted to the most recently scheduled task with IO port permissions. VULNERABLE SYSTEMS == Only x86 guests are vulnerable. All versions of Linux from 5.5 are potentially vulnerable. Linux is only vulnerable when running as x86 PV guest. Linux is not vulnerable when running as an x86 HVM/PVH guests. The vulnerability can only be exploited in domains which have been granted access to IO ports by Xen. This is typically only the hardware domain, and guests configured with PCI Passthrough. MITIGATION == Running only HVM/PVH guests avoids the vulnerability. CREDITS === This issue was discovered by Andy Lutomirski. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa329.patch Linux 5.5 and later $ sha256sum xsa329* cdb5ac9bfd21192b5965e8ec0a1c4fcf12d0a94a962a8158cd27810e6aa362f0 xsa329.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl8WytoMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ4wsH/0/2AMv2kb/Q6rfwlNLSrnDbK2b6bb/QUE+0GcHO vrJ7Su53xrt7mllk/P4jYmtXfyUeJzfsahdb5GQVh4GBxOA3YGgS5T4pdpnwNoFi NFZV35qOT0muwpjE/zoefKsESuvqWjd28Vssm4HrllJ4YqcGik9clo6Y5qWMFcFH rlgchZinl5RtqAzMnuOdirWir7Xika6KdkXWi56CjKZBB5ozoqfH5JKi/XbWbwrz ZoFHXwKRuckuQSxUlvdpmI7MZDyggii3OhdvA6fIMDWq58EjSVVatrvDxYsGRL8x 4PXmFPBp+871GjLQuQZ294fZH3DaZLWSrzvmwC8uZJr5uds= =Wdnv -END PGP SIGNATURE- xsa329.patch Description: Binary data
Xen Security Advisory 335 v2 (CVE-2020-14364) - QEMU: usb: out-of-bounds r/w access issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-14364 / XSA-335
version 2
QEMU: usb: out-of-bounds r/w access issue
UPDATES IN VERSION 2
Don't break the DSO by eliding the SoB on the patch.
Update Vulnerable Systems section.
Public release.
ISSUE DESCRIPTION
=
An out-of-bounds read/write access issue was found in the USB emulator
of the QEMU. It occurs while processing USB packets from a guest, when
'USBDevice->setup_len' exceeds the USBDevice->data_buf[4096], in
do_token_{in,out} routines.
IMPACT
==
A guest user may use this flaw to crash the QEMU process resulting in
DoS OR potentially execute arbitrary code with the privileges of the
QEMU process on the host.
VULNERABLE SYSTEMS
==
All versions of Qemu shipped with in-support versions of Xen are
vulnerable. This includes both qemu-traditional and qemu-xen.
The vulnerability can only be exploited when Qemu is used as a device
model. This configuration is only used by default for x86 HVM guests.
x86 PV, PVH and ARM guest do not use a device model by default.
Guests configured to use a Qemu stubdomain contain the code execution
within the stubdomain, and are therefore not considered vulnerable.
MITIGATION
==
No mitigation is available.
CREDITS
===
This issue was discovered by Xiao Wei of Qihoo 360 Inc.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa335-qemu.patchQEMU
xsa335-trad.patchXen unstable (SUPPORT.md update only)
$ sha256sum xsa335*
3af5f30c4fd21e3679fb749659f9e59d0ff335d092254352e128e7fee3340c41
xsa335-qemu.patch
2ed7b8bac4c473c6f89173a73485904be16785eb29ee18e189717d201381f27f
xsa335-trad.patch
$
"QEMU XEN TRADITIONAL"
==
This version of qemu is provided by the Xen Project for use as a
device model stub domain. In that configuration, there is not a
security problem and no action is needed.
But in other configurations, this version of qemu is lacking many
security fixes. It is beyond the capacity of the Xen Project Security
Team to address these. There is therefore no code resolution to
XSA-335 for users of qemu-xen-traditional who are not using device
model stub domains.
The patch xsa335-trad.patch included in this advisory is merely an
update for Xen's SUPPORT.md to document this situation.
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9Dr+0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ274H/3FIK/DecsmdqVFs9UjqCi+RABmz6dFsgUxQYH9c
ysZvN7R/BTR1m425+7tlPK1oglkFkHt6C9snc3+kTh/Bl5ktXakgVacoR6yeTh88
1yJQC3JmG9OaXGS4AR9hmE+Wg0XTlrmvzPMFxtWv055kpPVEG6FWhnhV8d0FavoI
RWnlelNSkXgai5zWlAqhF8jzR4EeEmOp4f/BtQX/cjZAodXZSYMvLW1zy3vx4Wik
ZpL4qkJLE9GHOYZF9Ng8zwWx7c1CIi76zwdUvUgPu6IjTBIpo0LPZxlkbF+CqYcp
rVFaAy7j7+xMOOJntlN2a/NAxD4zs+sCLF1legrfi+9uMH4=
=bMZs
-END PGP SIGNATURE-
xsa335-qemu.patch
Description: Binary data
xsa335-trad.patch
Description: Binary data
Xen Security Advisory 320 v1 (CVE-2020-0543) - Special Register Buffer speculative side channel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-0543 / XSA-320 Special Register Buffer speculative side channel ISSUE DESCRIPTION = This issue is related to the MDS and TAA vulnerabilities. Please see https://xenbits.xen.org/xsa/advisory-297.html (MDS) and https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details. Certain processor operations microarchitecturally need to read data from outside the physical core (e.g. to communicate with the random number generator). In some implementations, this operation is called a Special Register Read. In some implementations, data are staged in a single shared buffer, and a full cache line at a time is returned to the core which made the Special Register Read. On parts vulnerable to MFBDS or TAA, an attacker may be able to access stale data requested by other cores in the system. For more details, see: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html IMPACT == An attacker, which could include a malicious untrusted user process on a trusted guest, or an untrusted guest, can sample the contents of certain off-core accesses by other cores in the system. This can include data whose use may depend on the secrecy of the value, such as data from the Random Number Generator (e.g. RDRAND/RDSEED instructions). VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not believed to be vulnerable. Only Intel based processors are affected. Processors from other manufacturers (e.g. AMD) are not believed to be vulnerable. Please consult the Intel Security Advisory for details on the affected processors. MITIGATION == There is no mitigation available. RESOLUTION == New microcode is being released on affected parts to work around the vulnerability. It may be available via a firmware update (consult your hardware vendor), or available for OS loading (consult your dom0 OS vendor). On Xen 4.13 and later, OS microcode can be loaded at runtime. See https://xenbits.xen.org/docs/latest/admin-guide/microcode-loading.html#runtime-microcode-loading for details on the xen-ucode utility. Loading the microcode, either at boot or at runtime, suffices to mitigate the issue, as protections are active by default. The mitigations do have an impact on latency of individual RDRAND/RDSEED instructions. The patches below are for Xen, and offer boot time information, defaults selection, and opt-out controls. They are recommended to take, but not absolutely necessary for protection. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa320/xsa320-?.patchxen-unstable xsa320/xsa320-4.13-?.patch Xen 4.13.x xsa320/xsa320-4.12-?.patch Xen 4.12.x xsa320/xsa320-4.11-?.patch Xen 4.11.x xsa320/xsa320-4.10-?.patch Xen 4.10.x xsa320/xsa320-4.9-?.patchXen 4.9.x $ sha256sum xsa320*/* 84e4f66492042b08e69b0894ea7feb20c17c89a696cf95f05a8826fba4f26355 xsa320/xsa320-1.patch 5a3a06c72d0281fa1191ba18e39b836d2748400d9bf6a59dd45447850530c88b xsa320/xsa320-2.patch 759259ef88c980363d44e11d9c272f6a4a15918e5e6bcdfe971b1ce7ea160cd9 xsa320/xsa320-4.9-1.patch ebac2c011841c55c3c1e99d9e8afc53e56e54268d379ec8b904f6bfe6a1a5045 xsa320/xsa320-4.9-2.patch 5c622c74358ab21cbd27484c649f26df0f08e89ec333c346415bc51e35ba26c1 xsa320/xsa320-4.10-1.patch f112e34a6a4564a043926fc255a15c7e319001bd023a97ae2947228024e1c306 xsa320/xsa320-4.10-2.patch f24b51292be0cb5de80c6eff0b26983629dd48cc39ae5a331e2e38e15a6cf712 xsa320/xsa320-4.11-1.patch 03579810eaf2e9eeb1a82de4b50ff5c4b01e60b30ccf7609c9e3378ef576d81e xsa320/xsa320-4.11-2.patch 282537ffe2fd4332c0e061ddc537bea3e135a7bbd9253ec298becb49047323cf xsa320/xsa320-4.12-1.patch e4417429297354c233e8f5c261aff4888aae602f8c68897c09b16ea1aa44b1ca xsa320/xsa320-4.12-2.patch 611f2ab1a1c67e04767188d9803b6afd7d304e81a5b4f1eb1744d3e8a68ced66 xsa320/xsa320-4.13-1.patch cd1bc0071e72e2342ff4508ea3d937988694f4c03506b3afb3184f7d81aa1c86 xsa320/xsa320-4.13-2.patch $ NOTE REGARDING LACK OF EMBARGO == Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl7fufEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZCNgIALz6dLCvvznL7n3HFzYgKcelmOySjoZ52hJhg6ki N4C1AaPQmo1QPprycmuJ4uQIcLUP55Nh+h19V5PnRqSX1+7Qa8TXnv2TTpVK58fC JBfWBZ3xiXYdmaQOWYlJtD1Nq3vywA0LII9TZ7JdCUxjmPxn2y5ZOv6lRG6P9CVJ U+w3py0Zt32ZwYvVCbBPP49SdQmArH2BItEbGSQR5xeKnD/8Bx2/9odN0Mrnq5RQ euJxRled3nCGw6tWZJj3uYOy+dWWfmFwPFoFvI++zhrcwWGprcgjFuSGFbsGttMD ZB9+CZIJAHvgU4wu/B4SflHDgsmJS+iCmDR6e/NUlLohej0= =w+E7 -END PGP SIGNATURE
Xen Security Advisory 320 v2 (CVE-2020-0543) - Special Register Buffer speculative side channel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-0543 / XSA-320 version 2 Special Register Buffer speculative side channel UPDATES IN VERSION 2 Add a link to Intel's cross reference of affected hardware. Provide a suggested workaround for Ivy Bridge hardware, which is not receiving a microcode update. This includes a 3rd patch for each release. ISSUE DESCRIPTION = This issue is related to the MDS and TAA vulnerabilities. Please see https://xenbits.xen.org/xsa/advisory-297.html (MDS) and https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details. Certain processor operations microarchitecturally need to read data from outside the physical core (e.g. to communicate with the random number generator). In some implementations, this operation is called a Special Register Read. In some implementations, data are staged in a single shared buffer, and a full cache line at a time is returned to the core which made the Special Register Read. On parts vulnerable to MFBDS or TAA, an attacker may be able to access stale data requested by other cores in the system. For more details, see: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html https://software.intel.com/security-software-guidance/processors-affected-transient-execution-attack-mitigation-product-cpu-model IMPACT == An attacker, which could include a malicious untrusted user process on a trusted guest, or an untrusted guest, can sample the contents of certain off-core accesses by other cores in the system. This can include data whose use may depend on the secrecy of the value, such as data from the Random Number Generator (e.g. RDRAND/RDSEED instructions). VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not believed to be vulnerable. Only Intel based processors are affected. Processors from other manufacturers (e.g. AMD) are not believed to be vulnerable. Please consult the Intel Security Advisory for details on the affected processors. MITIGATION == Disabling RDRAND (and, where applicable, RDSEED) will avoid the vulnerability. It may have other adverse consequences, such as guests generating keys with weak random numbers, or guests hanging during boot waiting for entropy. A domain (guest, dom0, or service domain) which is runs with RDRAND disabled in CPUID, and whose software conforms to normal feature detection as specified in the Intel/AMD manuals, will not be vulnerable to snooping by other domains. But such a domain *can* still potentially snoop on any domains which are still using RDRAND. This mitigation is recommended to be applied globally, due to the practical complexity of auditing all software in a VM to confirm that there are no vulnerable uses of the RDRAND/RDSEED instructions. RDRAND and RDSEED can be disabled at the host level by booting Xen with `cpuid=no-rdrand,no-rdseed`, which will hide the feature from all domains including guests and dom0. Xen 4.12 and earlier require the appropriate patch 3 below for this mechanism to work. RDRAND and RDSEED can be disabled for guests with the following setting in the VM configuration file (xl.cfg): cpuid=["host:rdrand=0,rdseed=0]" (NB it would have to be merged into any existing cpuid= setting). Xen 4.9 and earlier require the appropriate patch 3 below for this mechanism to work. RESOLUTION == New microcode is being released on some affected parts to work around the vulnerability. It may be available via a firmware update (consult your hardware vendor), or available for OS loading (consult your dom0 OS vendor). For Ivy Bridge hardware, which is not receiving a microcode update, see MITIGATION, above. On Xen 4.13 and later, OS microcode can be loaded at runtime. See https://xenbits.xen.org/docs/latest/admin-guide/microcode-loading.html#runtime-microcode-loading for details on the xen-ucode utility. Loading the microcode, either at boot or at runtime, suffices to mitigate the issue, as protections are active by default. The mitigations do have an impact on latency of individual RDRAND/RDSEED instructions. The patches below are for Xen, and offer boot time information, defaults selection, opt-out controls, and uniform controls for hiding the RDRAND/RDSEED instructions. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa320/xsa320-?.patchxen-unstable xsa320/xsa320-4.13-?.patch Xen 4.13.x xsa320/xsa320-4.12-?.patch Xen 4.12.x xsa320/xsa320-4.11-?.patch Xen 4.11.x xsa320/xsa320-4.10-?.patch Xen 4.10.x xsa320/xsa320-4.9-?.patchXen 4.9.x $ s
Xen Security Advisory 317 v3 (CVE-2020-15566) - Incorrect error handling in event channel port allocation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-15566 / XSA-317
version 3
Incorrect error handling in event channel port allocation
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
The allocation of an event channel port may fail for multiple reasons:
1) Port is already in use
2) The memory allocation failed
3) The port we try to allocate is higher than what is supported by
the ABI (e.g 2L or FIFO) used by the guest or the limit set by an
administrator ('max_event_channels' in xl cfg).
Due to the missing error checks, only 1) will be considered as an error. All
the other cases will provide a "valid" port and will result to a crash when
trying to access the event channel.
IMPACT
==
When the administrator configured a guest to allow more than 1023
event channels, that guest may be able to crash the host.
When Xen is out-of-memory, allocation of new event channels will
result in crashing the host rather than reporting an error.
VULNERABLE SYSTEMS
======
Xen versions 4.10 and later are affected. (The special Xen 4.8
"Comet" branch for XSA-254 contains changes similar to those which led
to this vulnerability; so it is likely to be affected, but - like
mainline Xen 4.8 - that branch is longer security-supported.)
Older Xen versions are unaffected.
All architectures are affected.
The default configuration, when guests are created with xl/libxl, is
not vulnerable, because of the default event channel limit (see
Mitigation, below).
MITIGATION
==
The problem can be avoided by reducing the number of event channels
available to the guest no more than 1023. For example, setting
"max_event_channels=1023" in the xl domain configuration, or deleting
any existing setting (since 1023 is the default for xl/libxl).
For ARM systems, any limit no more than 4095 is safe.
For 64-bit x86 PV guests, any limit no more than 4095 is likewise safe
if the host configuration prevents the guest administrator from
substituting and running a 32-bit kernel (and thereby putting the
guest into 32-bit PV mode).
CREDITS
===
This issue was discovered by Amazon.
RESOLUTION
==
Applying the attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa317.patch Xen 4.10 - xen-unstable
$ sha256sum xsa317*
11e77dd8644cee40cee609d02e27d70655f3999005cae8c24fb2801980ebb4f2 xsa317.meta
17908035e2da07f6070fa8de345db68c96ed9bd78f8b114e43ba0194c1be3f15 xsa317.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the *patch* described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
And: deployment of the event channel limit reduction mitigation is NOT
permitted (except where all the affected systems and VMs are
administered and used only by organisations which are members of the
Xen Project Security Issues Predisclosure List). Specifically,
deployment on public cloud systems is NOT permitted.
This is because such a change can be visible to the guest, so it would
leak the preconditions for the vulnerability and maybe lead to
rediscovery.
Deployment of this, or similar mitigations, is permitted only AFTER
the embargo ends.
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl8EZ/gMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZQUwIAK8W8bZ0xml2bzAu4vsXi8QqhDX4VrpkgADYZS+M
BD8hpllQ+O/CiM5ZMECj7zaWYTt7+VrGrqK4jtf2REBs/sOWcO+k7KdEury4XCKf
jIG4CzCBHC46RVEKftiqQNTX2ebVBDwoj+1fGeIvm7OhcZ7f6KdhYPHvE2bU8D45
ghr2jw33HZHoG7IsPQvJn8u6wqd6l+7h0BxhgzO5U8pI+w3ZXRM4XAno+ERzs8LO
N5ffv8UeaMIpkHoYEdsKOK/ItjhoCASoWTFvbE90u7f2WbimFnBG3oCPEVPt89kv
Y/o0+0jBk+WjXbPChMmMu5WuQuKVFDelMXLLE6mjfhGAvnI=
=vEgE
-END PGP SIGNATURE-
xsa317.meta
Description: Binary data
xsa317.patch
Description: Binary data
Xen Security Advisory 319 v3 (CVE-2020-15563) - inverted code paths in x86 dirty VRAM tracking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-15563 / XSA-319 version 3 inverted code paths in x86 dirty VRAM tracking UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. IMPACT == A malicious or buggy HVM guest may cause the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS ====== Xen versions from 4.8 onwards are affected. Xen versions 4.7 and earlier are not affected. Only x86 systems are affected. Arm systems are not affected. Only x86 HVM guests using shadow paging can leverage the vulnerability. In addition there needs to be an entity actively monitoring a guest's video frame buffer (typically for display purposes) in order for such a guest to be able to leverage the vulnerability. x86 PV guests as well as x86 HVM guest using hardware assisted paging (HAP) cannot leverage the vulnerability. MITIGATION == Running only PV guests will avoid the vulnerability. For HVM guest explicitly configured to use shadow paging (e.g. via the `hap=0' xl domain configuration file parameter), changing to HAP (e.g. by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa319.patch xen-unstable, 4.13 - 4.9 $ sha256sum xsa319* 1fe0dc2e274776b8e1275f85129280f280f94ca4eabe6a8166113283dad93ed8 xsa319.meta c145f394f8ac7d8838c376a97e1850c4125c12e478fc66ebe025ae397b27e6ea xsa319.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER deployment of the "use HAP mode" mitigation described above is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because in that case the configuration change can be observed by guests, which could lead to the rediscovery of the vulnerability. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl8EZ/sMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ75YH/jX/sAs0icOgBtHkwVZHg318OBExxt9x+ehk/pxb i+1ZlS/IrJ8eJdHJYq8HYvAlxmtmFP1I0t+C9vmwbP4QMcR++RmKgdJI4+/sqCsB AMEnK+cVJSbHxD7y7eW2CPuU3h0cKx0H24JgtzA2ONse7dVz7RN+oa97D5IKryTL cBW8WroMn2InbKMCUy/5zj89NLAlbSuWSVZzQidDwzTITukzhZZ7Xw0+Q2yh1nkK S4kcmz7Bzzd5Mc1gFr1Eh1FxfmVVl5RxwDE//3a5VbmfPVo/f0kMOIWjXVd1R1dj x78SPrPojOAZbb8+f1LYqHmqzCgzvpa4EFbsOnsB7CBmP2Q= =bDFh -END PGP SIGNATURE- xsa319.meta Description: Binary data xsa319.patch Description: Binary data
Xen Security Advisory 328 v3 (CVE-2020-15567) - non-atomic modification of live EPT PTE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-15567 / XSA-328
version 3
non-atomic modification of live EPT PTE
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
When mapping guest EPT (nested paging) tables, Xen would in some
circumstances use a series of non-atomic bitfield writes.
Depending on the compiler version and optimisation flags, Xen might
expose a dangerous partially-written PTE to the hardware, which an
attacker might be able to race to exploit.
IMPACT
==
A guest administrator or perhaps even unprivileged guest user might
be able to cause denial of service, data corruption, or privilege
escalation.
VULNERABLE SYSTEMS
==
Only systems using Intel CPUs are vulnerable. Sytems using AMD CPUs,
and Arm systems, are not vulnerable.
Only systems using nested paging ("hap", aka nested paging, aka in
this case Intel EPT) are vulnerable.
Only HVM and PVH guests can exploit the vulnerability.
The presence and scope of the vulnerability depends on the precise
optimisations performed by the compiler used to build Xen. If the
compiler generates (a) a single 64-bit write, or (b) a series of
read-modify-write operations which are in the same order as the source
code, the hypervisor is not vulnerable.
For example, in one test build with gcc 8.3 with normal settings, the
compiler generated multiple (unlocked) read-modify-write operations in
source code order, which did *not* constitute a vulnerability.
We have not been able to survey compilers; consequently we cannot say
which compiler(s) might produce vulnerable code (with which code
generation options). The code clearly violates the C rules. So we
have chosen to issue this advisory.
MITIGATION
==
Running only PV guests will avoid this vulnerability.
Switching to shadow paging (e.g. using the "hap=0" xl domain domain
configuration file parameter) will avoid exposing the vulnerability to
those guests.
Manual inspection of the generated assembly code might allow a
suitably qualified person to say that a particular build is not
vulnerable.
There is no less broad mitigation.
CREDITS
===
This issue was discovered by Jan Beulich of SUSE.
For patch 1:
Reviewed-by: Roger Pau Monné
For patch 2:
From: Roger Pau Monné
Reported-by: Jan Beulich
Signed-off-by: Roger Pau Monné
RESOLUTION
==
Applying the appropriate pair of attached patches resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa328/xsa328-?.patchxen-unstable
xsa328/xsa328-4.13-?.patch Xen 4.13.x
xsa328/xsa328-4.12-?.patch Xen 4.12.x
xsa328/xsa328-4.11-?.patch Xen 4.11.x, Xen 4.10.x
xsa328/xsa328-4.9-?.patchXen 4.9.x
$ sha256sum xsa328* xsa328*/*
61ceb3d039c3ebb06f480a17593b367b01e7c1e5cc3669d77caecb704fbc7071 xsa328.meta
cae53f7e6c46fe245790036279bc50eaa10e4271790e871ad8a7d446629b2e12
xsa328/xsa328-1.patch
d61354a992869451cd7a3c92254672b5e253d1a994135cf9b4a5c784be0a07ef
xsa328/xsa328-2.patch
018412fba6f153c1d6b03fc2fa6f3ac381060efe6a8651404462028d24c830a8
xsa328/xsa328-4.9-1.patch
f3deb26e0ce27c385ab16065a0ba67b86a228afd949c0a6a78b9d48366fc2554
xsa328/xsa328-4.9-2.patch
a600ecef784485e8608cd4549f756ffa24705747a4d876147f9ba64fff118580
xsa328/xsa328-4.11-1.patch
f3deb26e0ce27c385ab16065a0ba67b86a228afd949c0a6a78b9d48366fc2554
xsa328/xsa328-4.11-2.patch
d608921359e561f9c594c9f8f7ee02432518a229ecea638d472ab91227d705ec
xsa328/xsa328-4.12-1.patch
a51162c019e7e6ed394faa7d40c932456059b7b76a784dc7886dd0a47c43da0b
xsa328/xsa328-4.12-2.patch
51a41fae885aed40839887da473e0c8ab4c4d897a121f5fac2cc3c6c0188d6d2
xsa328/xsa328-4.13-1.patch
a51162c019e7e6ed394faa7d40c932456059b7b76a784dc7886dd0a47c43da0b
xsa328/xsa328-4.13-2.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Polic
Xen Security Advisory 327 v3 (CVE-2020-15564) - Missing alignment check in VCPUOP_register_vcpu_info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2020-15564 / XSA-327 version 3 Missing alignment check in VCPUOP_register_vcpu_info UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen address space so it can be directly accessed. On Arm, the region is accessed with instructions which require a specific alignment. Unfortunately, there is no check that the address provided by the guest will be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a misaligned address. IMPACT == A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected. MITIGATION == There is no mitigation. CREDITS === This issue was discovered by Julien Grall of Amazon. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa327.patch Xen 4.9 - xen-unstable $ sha256sum xsa327* f046eefcc1368708bd1fafc88e063d3dbc5c4cdb593d68b3b04917c6cdb7bcb5 xsa327.meta 1d057695d5b74ce2857204103e943caeaf773bc4fb9d91ea78016e01a9147ed7 xsa327.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patch and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl8EaVAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZcqIIAKpb992pMq1jFStIGPhk6HsaIhxVEGep67eJHq9d TMaFiyBix125djY0zV8KaznmZmRpM2pNKVsIkGe1XHgtEMcWgMAYARejJLRC4UnW xHhpunI7rJMQc1vL5ZGxAFbVYF6U/PX0rwESwQb2/Rt0eLBTAmH4m25TQiSEnrkM 3C4Dbk3puCbaeB7VGiyccK07hh6qQhEO8s1FhZTNVTaqqcNWZYqy/SbmRYHiT/in 2dK6XOiBgRhHnjsDDoXj5abSMb00KnJ9PkWu8RC2b7+BVZJUii1557T8zpDo9Fyl CJ3YXrekd+gQSFxgwCts00BbLr2NUf3uqEtpY1EEV7UKmvQ= =fPiG -END PGP SIGNATURE- xsa327.meta Description: Binary data xsa327.patch Description: Binary data
[Xen-devel] Xen Security Advisory 300 v1 - Linux: No grant table and foreign mapping limits
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-300
Linux: No grant table and foreign mapping limits
ISSUE DESCRIPTION
=
Virtual device backends and device models running in domain 0, or
other backend driver domains, need to be able to map guest memory
(either via grant mappings, or via the foreign mapping interface).
For Linux to keep track of these mappings, it needs to have a page
structure for each one. In practice the number of page structures is
usually limited. In PV dom0, a range of pfns are typically set aside
at boot ("pre-ballooned") for this purpose; for PVH and Arm dom0s, no
memory is set aside to begin with. In either case, when more of this
"foreign / grant map pfn space" is needed, dom0 will balloon out extra
pages to use for this purpose.
Unfortunately, in Linux, there are no limits, either on the total
amount of memory which dom0 will attempt to balloon down to, nor on
the amount of "foreign / grant map" memory which any individual guest
can consume.
As a result, a malicious guest may be able, with crafted requests to
the backend, to cause dom0 to exhaust its own memory, leading to a
host crash; and if this is not possible, it may be able to monopolize
all of the foreign / grant map pfn space, starving out other guests.
IMPACT
==
Guest may be able to crash domain 0 (Host Denial-of-Service); or may
be able to starve out I/O requests from other guests (Guest
Denial-of-Service).
VULNERABLE SYSTEMS
==
All versions of Linux are vulnerable.
All Arm dom0s are vulnerable; on x86, PVH dom0 is generally vulnerable,
while PV dom0's vulnerability depends on what, if any, "dom0_mem="
option was passed to Xen.
MITIGATION
==
On PV dom0, the amount of "pre-ballooned" memory can be increased by
limiting dom0 memory via "dom0_mem=", but avoiding use of the
"dom0_mem=max:" form of the command line option, or by making
the delta between "actual" and "maximum" sufficiently large. This makes
the attack more difficult to accomplish.
CREDITS
===
This issue was discovered by Julien Grall of ARM.
RESOLUTION
==
Applying the appropriate attached patch resolves the domain 0 memory
exhaustion issue.
NOTE: This does NOT fix the guest starvation issue. Fixing fixing
this issue is more complex, and it was determined that it was better
to work on a robust fix for the issue in public. This advisory will
be updated when fixes are available.
xsa300-linux-5.1.patch Linux 4.4 ... 5.2-rc
$ sha256sum xsa300*
9c8a9aec52b147f8e8ef41444e1dd11803bacf3bd4d0f6efa863b16f7a9621ac
xsa300-linux-5.1.patch
$
NOTE ON LACK OF EMBARGO
===
The lack of predisclosure is due to a short schedule set by the
discoverer, and efforts to resolve the advisory wording.
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl0knK4MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZVp0H/2P+7XAtIAS2owhUnTBPSmM/93LZBHr67DCGSoix
afHEumj4b3omIssAEo912BXpG0tjzCBlStwacRDc/11Ku4XtB/hlr5TG89c2tfVd
QMtvWeAdDjWE2YkwZ3TK5BgaYMwoUSMdwXtG2NGpVGFj4jy4AUL5e+sZKAiMTbl2
f3ursyyts/cgJTLq1KHfX3jVlqcRLvv0yGXLsZ0BQbktnEpptETPPtBvEQQ+Uqkb
WjqxCvzmh0Szc9mnhLSxS2LDA6W/y/r37XawpwJIZNpE12+sQRZ48KqeFysTK4Yp
MRZokgzOBOXfHVa25LpgtZzL5DmRR5AfWYkmgmIX8s7NaH8=
=OKdx
-END PGP SIGNATURE-----
xsa300-linux-5.1.patch
Description: Binary data
_______
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 300 v2 - Linux: No grant table and foreign mapping limits
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-300
version 2
Linux: No grant table and foreign mapping limits
UPDATES IN VERSION 2
Drop inapplicable "Deployment during embargo" section.
Rewrite for clarity, and to remove most references to dom0. The issue
is equally applicable to domU's providing backend services.
Add information about the arbitrary limit for userspace backends.
ISSUE DESCRIPTION
=
Virtual device backends and device models running in domain 0, or
other backend driver domains, need to be able to map guest memory
(either via grant mappings, or via the foreign mapping interface).
Inside Xen, mapped grants are tracked by the maptrack structure. The
size of this structure is chosen during domain creation, and has a
fixed upper bound for the lifetime of the domain.
For Linux to keep track of these mappings, it needs to have a page
structure for each one. In practice the number of page structures is
usually limited. In PV guests, a range of pfns are typically set
aside at boot ("pre-ballooned") for this purpose. For HVM/PVH and Arm
guests, no memory is set aside to begin with. In either case, when
more of this "foreign / grant map pfn space" is needed, Linux will
balloon out extra pages to use for this purpose.
Unfortunately, in Linux, there are no limits, either on the total
amount of memory which the domain will attempt to balloon out, nor on
the amount of "foreign / grant map" memory which any individual guest
can consume.
For Linux userspace backends (e.g. QEMU) which use /dev/xen/gnttab or
/proc/xen/gnttab, there is an arbitrary mapping limit which, if hit,
will prevent further mappings from being established.
As a result, a malicious guest may be able to, with crafted requests,
cause a backend Linux domain to either:
1) Fill the maptrack table in Xen and/or hit the userspace limit.
This will starve I/O from other guests served by the same backend.
2) Balloon out sufficient RAM to cause it to swap excessively, or run
completely out of memory. This may starve all operations from the
domain, including I/O from other guests, or may cause a crash of
the domain.
IMPACT
==
Guest may be able to crash backend Linux domains, or starve operations
inside the domain, including the processing of guest I/O requests
(Guest Denial-of-Service).
If the backend is domain 0, which is the most common configuration,
then host-wide operations may be starved, or the host may crash (Host
Denial-of-Service).
VULNERABLE SYSTEMS
==
All versions of Linux are vulnerable. Only Linux guests acting as
backend domains for other guests may be exploited.
All Arm domains are vulnerable, as are x86 PVH/HVM guests. The
vulnerability of x86 PV guests depends on how they were configured at
boot.
MITIGATION
==
PV guests can be constructed with "pre-ballooned" memory, by building
it with maxmem > memory. See `man 5 xl.cfg` for full details of these
two parameters.
For PV dom0, these are controlled by Xen's "dom0_mem=$X,max:$Y"
command line parameter.
The larger the difference between memory and maxmem, the more space
Linux has to fill with grant/foreign mappings before it will start
ballooning out real memory to satisfy further mapping requests. This
makes the attack more difficult to accomplish.
CREDITS
===
This issue was discovered by Julien Grall of ARM.
RESOLUTION
==
Applying the appropriate attached patch resolves the backend memory
exhaustion issue.
NOTE: This does NOT fix the guest starvation issue. Fixing fixing
this issue is more complex, and it was determined that it was better
to work on a robust fix for the issue in public. This advisory will
be updated when fixes are available.
xsa300-linux-5.2.patch Linux 4.4 ... 5.2
$ sha256sum xsa300*
9c8a9aec52b147f8e8ef41444e1dd11803bacf3bd4d0f6efa863b16f7a9621ac
xsa300-linux-5.2.patch
$
NOTE ON LACK OF EMBARGO
===
The lack of predisclosure is due to a short schedule set by the
discoverer, and efforts to resolve the advisory wording.
-BEGIN PGP SIGNATURE-
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl0xyy0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZyzUH/3hhOLPLuiTnKQd3idx0iIrpRkQfcdl9pxWWARWx
xiVKyyMIajokrq5besT01Ztizz6B80DN+m4W14yi+j8nDyR3W4v/JriZQY48Tj1i
nd+jvBGfvQcjNc5WaVjBtU/x9j0HDCUrBP+uJMGdt9jl6fppvMwnBcv/OeEvl/eE
TjwEMs/RQ69LcjpwGGPSAh8AR2i1+oL3LiHtwO31hdkw0Ritqa32Uw4c+ENuo/OE
PApIX8O8TMgRX0/LriGy6dtlb/L4SljTPa592EHH1cPfDelHmzpWEeIx77nbq8v/
/Ex6Gjd/19ArWvofxQkQk1+aNfvBPnPCaboc7JrlCuFEDP4=
=OcOD
-END PGP SIGNATURE-
xsa300-linux-5.2.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Xen Security Advisory 396 v3 (CVE-2022-23036,CVE-2022-23037,CVE-2022-23038,CVE-2022-23039,CVE-2022-23040,CVE-2022-23041,CVE-2022-23042) - Linux PV device frontends vulnerable to attacks by backends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-23036,CVE-2022-23037,CVE-2022-23038,CVE-2022-23039,CVE-2022-23040,CVE-2022-23041,CVE-2022-23042 / XSA-396 version 3 Linux PV device frontends vulnerable to attacks by backends UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042 IMPACT == Due to race conditions and missing tests of return codes in the Linux PV device frontend drivers a malicious backend could gain access (read and write) to memory pages it shouldn't have, or it could directly trigger Denial of Service (DoS) in the guest. VULNERABLE SYSTEMS == All Linux guests using PV devices are vulnerable in case potentially malicious PV device backends are being used. MITIGATION == There is no mitigation available other than not using PV devices in case a backend is suspected to be potentially malicious. RESOLUTION == Applying the attached patches resolves this issue. xsa396-linux-*.patch Linux upstream $ sha256sum xsa396* d21d2d2c499d8e7c1cbc347d9df118b27af7d7c9ca5c104fcf1fef022ba6b92d xsa396-linux-01.patch c150c7873497b4d9807fcfe2a4a4831b033597db3d4c3dfaada1e647db1395fa xsa396-linux-02.patch 6439ac16b6d6b29d6773d00895776a7392a321caa01f569062c4140d3d66167c xsa396-linux-03.patch 2cc0b472514be47690ef257ab8d296bbec1827d18f98e1f1bbbfea53aafec78c xsa396-linux-04.patch cd6b6e65fe9915f98b04363bf1f22ddbd7c448215d52858ad1a2318bb1f034c8 xsa396-linux-05.patch 353e4de564897ad07120b17aa7a6a22b90fba6e65f39c20fe561ba06405656f3 xsa396-linux-06.patch bf923c3bc92a908215d5ade016d27f56d1e445da88b04e1e1d4530ea5b139be3 xsa396-linux-07.patch 0a306ed20e4259e2a3583bfab14672a245bd33b24e95e5df8bfc30a25f7e18c6 xsa396-linux-08.patch 130b8305ba8c10e2942553078b845899ef79c5570692a499569a526b1e39d4fe xsa396-linux-09.patch 1f70bdc0a5c1ff1b538d8cbec17e99af5888669f3a33ad8a02d2026719ad4bc9 xsa396-linux-10.patch 48fd782c6b0b705ccb59885d0e1562873f44478ea87f705f08ce18336bc19257 xsa396-linux-11.patch d720350d36f7434e2cad1cb0ae0ed48776ad870a7b1e61cdd08d80fb4a787d59 xsa396-linux-12.patch $ CREDITS === This issue was discovered by Demi Marie Obenour and Simon Gaiser of Invisible Things Lab. DEPLOYMENT DURING EMBARGO = Deployment of patches or mitigations is NOT permitted (except where all the affected VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because the patches need to be applied in the affected guests. Switching from PV to non-PV devices is observable by the guests and has usually a bad performance impact. Deployment is permitted only AFTER the embargo ends. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE
Xen Security Advisory 397 v2 (CVE-2022-26356) - Racy interactions between dirty vram tracking and paging log dirty hypercalls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-26356 / XSA-397 version 2 Racy interactions between dirty vram tracking and paging log dirty hypercalls UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Activation of log dirty mode done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while another CPU is still in the process of tearing down the structures related to a previously enabled log dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both operations and can lead to entries being added in already freed slots, resulting in a memory leak. IMPACT == An attacker can cause Xen to leak memory, eventually leading to a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions from at least 4.0 onwards are vulnerable. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only domains controlling an x86 HVM guest using Hardware Assisted Paging (HAP) can leverage the vulnerability. On common deployments this is limited to domains that run device models on behalf of guests. MITIGATION == Using only PV or PVH guests and/or running HVM guests in shadow mode will avoid the vulnerability. CREDITS === This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa397.patch xen-unstable xsa397-4.16.patch Xen 4.16.x - Xen 4.15.x xsa397-4.14.patch Xen 4.14.x - Xen 4.13.x xsa397-4.12.patch Xen 4.12.x $ sha256sum xsa397* 49c663e2bb9131dbc2488e12487f79bdf0dafd51a32413cbf3964e39d8779cae xsa397.patch 24f95f47b79739c9cb5b9110137c802989356c82d0aa27963b5ac7e33f667285 xsa397-4.12.patch 9af14f90ba10d074425eb6072a6c648082c92c1cf8b6f881f57ed2fc13d6e49d xsa397-4.14.patch ff5dd3b7a8dbf349c3b832b7916322c0296fa59c7f9cd2ba30858989add5f65c xsa397-4.16.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software (except to other members of the predisclosure list) or deployment of mitigations is prohibited. Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmJMJDEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZOUMH/RRZ8aMaoywqTV38SeTFne2tFT5jnWPPXR1ZGCvh 825hmSqzcYUaILbWFruUfT2PdpGoU9Eprz3xWXBDwgsUEGvKt7ZhGoWvxzXASlDh cPRh/XwQVEEYsB1cRSk/GoLxLCQEV8oGNpmAcjEM4K1dG0VbVaRD0W2thNCmyPcv d7aTkAdD2IE8NU4hX8YGN6v+UCkjrgzL0AF/hff9CMj7Sn/wBRrdStLT0LDZU20c G/5+9nsOAVM7EwrzImI5Lx9KELyHwl37XUPffbftyTLUofdHJ5PK40J1tNIRS/RW YYvs2alF7ng7LlwB/Go8gtn4XRx6xZidceYrUk22oB4JBqo= =Fje3 -END PGP SIGNATURE- xsa397.patch Description: Binary data xsa397-4.12.patch Description: Binary data xsa397-4.14.patch Description: Binary data xsa397-4.16.patch Description: Binary data
Xen Security Advisory 399 v2 (CVE-2022-26357) - race in VT-d domain ID cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-26357 / XSA-399 version 2 race in VT-d domain ID cleanup UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed. IMPACT == The precise impact is system specific, but would typically be a Denial of Service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS == Xen versions 4.11 through 4.16 are vulnerable. Xen versions 4.10 and earlier are not vulnerable. Only x86 systems with VT-d IOMMU hardware are vulnerable. Arm systems as well as x86 systems without VT-d hardware or without any IOMMUs in use are not vulnerable. Only x86 guests which have physical devices passed through to them can leverage the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa399.patch xen-unstable xsa399-4.16.patch Xen 4.16.x - Xen 4.13.x xsa399-4.12.patch Xen 4.12.x $ sha256sum xsa399* 53b9745564eb21f70dbb7bd7194ff3518f29cd9715c68e9dd7eff25812968019 xsa399.patch 16c3327a60d8ab6c3524f10f57d63efaf2e3e54b807bc285a749cd1a94392a30 xsa399-4.12.patch 79d0f5a0442dec0a806d77a722a1d2c04793572fe0b564bf86dcd1c6d992a679 xsa399-4.16.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because removal of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmJMJDcMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZpo8H/AqiAS0l5WJWl00bTQ4Q69REzd83m9Y3+UnUqRaf JUFWo4R1m4V2zJlq0E3TR/2ZS1RkXFJxlmXQyzueFmDEvMV2oKB0ids5ta1oUO2E eiQxdSFbTLrLnhI+4IxbTHHy+ovSHT/SKPeo1Zd1tXHfZ35g1OgGTYHHqj7RKJHp SyZT4iuAKjIr61M4NBKJcycpfRidlXEDvAotDX3jBQ06t3vgs/12nwe5LzzeV2V4 sIDjpeDGNKzgT2NgLP2b+XMEUg1259iWb19tS3PPNJaLKSvQqTBOFjK+sqh7ACXV v6ph2Yy0Q/ZP+N9DvCeBCPEU9A9RhmPYzobU+Lc/T85SrQ4= =sp/Q -END PGP SIGNATURE- xsa399.patch Description: Binary data xsa399-4.12.patch Description: Binary data xsa399-4.16.patch Description: Binary data
Xen Security Advisory 386 v1 (CVE-2021-28702) - PCI devices with RMRRs not deassigned correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28702 / XSA-386 PCI devices with RMRRs not deassigned correctly ISSUE DESCRIPTION = Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR"). These are typically used for platform tasks such as legacy USB emulation. If such a device is passed through to a guest, then on guest shutdown the device is not properly deassigned. The IOMMU configuration for these devices which are not properly deassigned ends up pointing to a freed data structure, including the IO Pagetables. Subsequent DMA or interrupts from the device will have unpredictable behaviour, ranging from IOMMU faults to memory corruption. IMPACT == Administrators of guests which have been assigned RMRR-using PCI devices can cause denial of service and other problems, possibly including escalation of privilege. VULNERABLE SYSTEMS == All versions of Xen from at least 4.4 onwards are vulnerable. Only Intel x86 systems are affected. AMD x86 systems, and Arm systems, are all unaffected. Only systems using PCI passthrough are affected. (And then, only if the assigned devices have RMRRs, but whether a device advertises RMRRs is not easy to discern.) MITIGATION == There is no mitigation (other than not passing through PCI devices with RMRRs to guests). RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa386.patch xen-unstable - Xen 4.12.x $ sha256sum xsa386* f2f83c825e249bba9454437b48bbd8307fe7a224f56484388a67af124dfd279b xsa386.patch $ NOTE CONCERNING LACK OF EMBARGO === This issue was reported and debugged in public before the security nature became apparent. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmFcnH8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZje0H+QE5A0ZvoaJ5VupZYjAt5ynbQjVqxwxqAxZDTvP7 t3gtpsHSYgrHW+3giULxjGU0ZUGF9daO1JEIZCPCbUdIlmGqGEXdDoqtz0GrXCJJ swQFeXQVmn9lV4KMTHO0BvGw5aZOft1VgGNrixd3vckFl7c5G8sWFdl7IU7FPDTQ LiLMg6f1oOntBYjNZUZ2210jqct9GZ4ugURRufwZrwYIpc9H5pFnZAFHKismX/2m x/PCdmOCeivytmUPA4k62oJVpJdysAL+31XkZz8bbAhjFsUmYBJscW2T5mSfaYIp TaSrg9WBV+TVW7aNE2iittE2O0/YyOWfpUVh6lliECeFdd0= =aNEo -END PGP SIGNATURE- xsa386.patch Description: Binary data
Xen Security Advisory 386 v2 (CVE-2021-28702) - PCI devices with RMRRs not deassigned correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28702 / XSA-386 version 2 PCI devices with RMRRs not deassigned correctly UPDATES IN VERSION 2 Updated/corrected information about vulnerable versions. Upstream Xen 4.12 is not affected. There is no harm from applying the patch to an unaffected version. ISSUE DESCRIPTION = Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR"). These are typically used for platform tasks such as legacy USB emulation. If such a device is passed through to a guest, then on guest shutdown the device is not properly deassigned. The IOMMU configuration for these devices which are not properly deassigned ends up pointing to a freed data structure, including the IO Pagetables. Subsequent DMA or interrupts from the device will have unpredictable behaviour, ranging from IOMMU faults to memory corruption. This bug has existed since at least Xen 4.4 But it was previously masked by a tangentially-related misbehaviour; that misbehaviour was corrected in f591755823a7 IOMMU/PCI: don't let domain cleanup continue when device de-assignment failed which was backported to supported stable branches. IMPACT == Administrators of guests which have been assigned RMRR-using PCI devices can cause denial of service and other problems, possibly including escalation of privilege. VULNERABLE SYSTEMS == For stable Xen releases: 4.13.4, 4.14.3 and 4.15.1 are vulnerable. Other versions of Xen released by the Xen Project are not affected. For Xen git branches: the HEADs of 4.13 and later (including xen-unstable) were vulnerable, up until 2021-10-05 (when the patch in this advisory was committed). 4.12 and earlier are not affected. In detail: code that has the following patch applied, is vulnerable: IOMMU/PCI: don't let domain cleanup continue when device de-assignment failed That patch is currently in upstream stable branches 4.13 onwards and was included in the most recent stable point releases of each Xen version. Other downstream Xen builds may be affected if that patch was backported. Only Intel x86 systems are affected. AMD x86 systems, and Arm systems, are all unaffected. Only systems using PCI passthrough are affected. (And then, only if the assigned devices have RMRRs, but whether a device advertises RMRRs is not easy to discern.) MITIGATION == There is no mitigation (other than not passing through PCI devices with RMRRs to guests). RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa386.patch xen-unstable - Xen 4.13.x $ sha256sum xsa386* f2f83c825e249bba9454437b48bbd8307fe7a224f56484388a67af124dfd279b xsa386.patch $ NOTE CONCERNING LACK OF EMBARGO === This issue was reported and debugged in public before the security nature became apparent. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmFfBvkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZY20H/jWe2XVSU6R+cOv4GbhWL5sWBv4skLZ07yq77p8i JB9nJXdVkyHJPSkENzggGGiygiHMJFSD5cLvczJp1IbAlQKQlZt/oVG9oTWHHeqO joabwgZ9UyNW8/beCigRo1PYdiWI7tMsLp3D/LAjE8+ZhBRjD0NKLyWK26Uw0R8A Su5tApmlBGx0BJzQm4BUWiyog86fPoNcBkP1hRJfj1BfXRjVYB5MsaPCtMhsqBlG CFjDJ51Wn4Esxkg22e/429MbbExIAJUZoxuOWDk/D7nQShQNBTfqci4pfcaf5E+f Mxi32bIr/XY5LLgf0Opu5Sl2JP3s7Ik3IDlSa+wYoGIZWB4= =Ti35 -END PGP SIGNATURE- xsa386.patch Description: Binary data
Xen Security Advisory 390 v1 (CVE-2021-28710) - certain VT-d IOMMUs may not work in shared page table mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28710 / XSA-390 certain VT-d IOMMUs may not work in shared page table mode ISSUE DESCRIPTION = For efficiency reasons, address translation control structures (page tables) may (and, on suitable hardware, by default will) be shared between CPUs, for second-level translation (EPT), and IOMMUs. These page tables are presently set up to always be 4 levels deep. However, an IOMMU may require the use of just 3 page table levels. In such a configuration the lop level table needs to be stripped before inserting the root table's address into the hardware pagetable base register. When sharing page tables, Xen erroneously skipped this stripping. Consequently, the guest is able to write to leaf page table entries. IMPACT == A malicious guest may be able to escalate its privileges to that of the host. VULNERABLE SYSTEMS ====== Xen version 4.15 is vulnerable. Xen versions 4.14 and earlier are not vulnerable. Only x86 Intel systems with IOMMU(s) in use are affected. Arm systems, non-Intel x86 systems, and x86 systems without IOMMU are not affected. Only HVM guests with passed-through PCI devices and configured to share IOMMU and EPT page tables are able to leverage the vulnerability on affected hardware. Note that page table sharing is the default configuration on capable hardware. Systems are only affected if the IOMMU used for a passed through device requires the use of page tables less than 4 levels deep. We are informed that this is the case for some at least Ivybridge and earlier "client" chips; additionally it might be possible for such a situation to arise when Xen is running nested under another hypervisor, if an (emulated) Intel IOMMU is made available to Xen. MITIGATION == Suppressing the use of shared page tables avoids the vulnerability. This can be achieved globally by passing "iommu=no-sharept" on the hypervisor command line. This can also be achieved on a per-guest basis via the "passthrough=sync_pt" xl guest configuration file option. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa390.patch xen-unstable - Xen 4.15.x $ sha256sum xsa390* 34d3b59a52c79bd7f9d963ca44ee5cfee08274d49961726e81c34eeff6e6cd37 xsa390.patch $ CREDITS === This issue was discovered by Jan Beulich of SUSE. NOTE REGARDING LACK OF EMBARGO == This fix for issue was submitted in public before realizing the security aspect. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmGXsGUMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZiMkH/2t+q/yAO7srnKdt1yLhOcG/tok0pdSLe5b3ayES ZktW69wnSlQ/TeH96A64pZKxXbQpRh3cDbjn2xedCDGIOyaKuObgPY7aYfuvtOxN /6a3P3qUf2oxm5/nS0KG6kHX69gptXupvgCPwl2i1KWARi4uMEm76N7lCe3o8fFd s8HNfLvJ0tX6pXtOQjeQEt73fDWQ/hwKGGJctFI1hrvy01erqHDdZrYiJAO6vp8z c9LU1o8dIQSUg2dm5GSX5DCX6xEzOh6sT53CDQ7W5gTn+SnCGr7FT1iTeXYeTFSN EaYZVynkaxQeCXsoJO0K2o7lwwKvUrQ6GNhqdd4iOR/annY= =P/qb -END PGP SIGNATURE- xsa390.patch Description: Binary data
Xen Security Advisory 389 v3 (CVE-2021-28705,CVE-2021-28709) - issues with partially successful P2M updates on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28705,CVE-2021-28709 / XSA-389 version 3 issues with partially successful P2M updates on x86 UPDATES IN VERSION 3 Add CVE numbers to patches. Public release. ISSUE DESCRIPTION = x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). In some cases the hypervisor carries out the requests by splitting them into smaller chunks. Error handling in certain PoD cases has been insufficient in that in particular partial success of some operations was not properly accounted for. There are two code paths affected - page removal (CVE-2021-28705) and insertion of new pages (CVE-2021-28709). (We provide one patch which combines the fix to both issues.) IMPACT == Malicious or buggy guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS == All Xen versions from 3.4 onwards are affected. Xen versions 3.3 and older are believed to not be affected. Only x86 HVM and PVH guests started in populate-on-demand mode are believed to be able to leverage the vulnerability. Populate-on-demand mode is activated when the guest's xl configuration file specifies a "maxmem" value which is larger than the "memory" value. MITIGATION == Not starting x86 HVM or PVH guests in populate-on-demand mode is believed to allow avoiding the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa389.patch xen-unstable xsa389-4.15.patch Xen 4.15.x xsa389-4.14.patch Xen 4.14.x xsa389-4.13.patch Xen 4.13.x xsa389-4.12.patch Xen 4.12.x $ sha256sum xsa389* c00f5b07594a6459bdd6f7334acc373bc3b0c14a5b0e444ec624ac60f857fc6f xsa389.patch bf0d66623c3239e334a17332035be5d7c7e33cfdd7f04f9b385f70ce8fa92752 xsa389-4.12.patch 2737affcf1e0fae5d412067ea8c7fe1cc91a28fa22f3f7e97a502cbd032582cc xsa389-4.13.patch b243284679b32ab8c817a2e41562d8694d9781fa8096c268bb41b0cd91684baa xsa389-4.14.patch 0a213e141089fe7808eae067b3c43beed6c7d5887fa4c901e8f9352618788e5a xsa389-4.15.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change is recognizable by the affected guests. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmGc2jkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZkOAIAInsof4UP5VTDcLtiwCvGskCXZT0SwbJ5OKbmxG7 RmPJg+R5sy89aHyJ4BP4eRfgrfbG35qBSCB5zLHy2FR3oioRmDz3y4KAFP3hXJRc B0hSNM9Al9nEfdt0YQeVxt297X0Ouz/bihLoHXKOTZ2AqKcafu9GRIdK0Kcj1v49 azcW1ndfAkIEYDGvtcdZDXYT3CyjLusQme3pweohZGwcQW6UYg7DhRKl0KPQZP/L paQZd60walNWgDcV7qfMnWit2jYxF4AptLW8c+KFig7qorLE5z9Xj7AIJ6kGriry fnwy/DE2xRr4IxWk/FsJgDxeAS6mv3KQ2Mpgx2bRAD0jB6I= =3P7k -END PGP SIGNATURE- xsa389.patch Description: Binary data xsa389-4.12.patch Description: Binary data xsa389-4.13.patch Description: Binary data xsa389-4.14.patch Description: Binary data xsa389-4.15.patch Description: Binary data
Xen Security Advisory 387 v2 (CVE-2021-28703) - grant table v2 status pages may remain accessible after de-allocation (take two)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28703 / XSA-387 version 2 grant table v2 status pages may remain accessible after de-allocation (take two) UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Guest get permitted access to certain Xen-owned pages of memory. The majority of such pages remain allocated / associated with a guest for its entire lifetime. Grant table v2 status pages, however, get de-allocated when a guest switched (back) from v2 to v1. The freeing of such pages requires that the hypervisor know where in the guest these pages were mapped. The hypervisor tracks only one use within guest space, but racing requests from the guest to insert mappings of these pages may result in any of them to become mapped in multiple locations. Upon switching back from v2 to v1, the guest would then retain access to a page that was freed and perhaps re-used for other purposes. This bug was fortuitously fixed by code cleanup in Xen 4.14, and backported to security-supported Xen branches as a prerequisite of the fix for XSA-378. IMPACT == A malicious guest may be able to elevate its privileges to that of the host, cause host or guest Denial of Service (DoS), or cause information leaks. VULNERABLE SYSTEMS == All Xen branches up to and including 4.13 are vulnerable, but only if the patches for XSA-378 have not been applied. Xen versions 4.13.4, 4.14.x and 4.15.x are not affected. Only x86 HMV and PVH guests permitted to use grant table version 2 interfaces can leverage this vulnerability. x86 PV guests cannot leverage this vulnerability. On Arm, grant table v2 use is explicitly unsupported. MITIGATION == Running only PV guests will avoid this vulnerability. Suppressing use of grant table v2 interfaces for HVM or PVH guests will also avoid this vulnerability. CREDITS === This issue was discovered by Patryk Balicki and Julien Grall of Amazon. RESOLUTION == Applying the following patch resolves the issue: x86/p2m: don't assert that the passed in MFN matches for a remove This patch was supplied with XSA-378, as one of 378's prerequisites. The fix has already been applied to Xen stable branches as follows: c65ea16dbcafbe4fe21693b18f8c2a3c5d14600e in Xen 4.14.x, 4.15.x f50fbddbae81fcccae56d27317bd71cc0e678ba2 in Xen 4.13.4 d44643199c96ac22491ae002d3bcd1c989b95ea4 in xen.git#stable-4.12 66f400c71d12fe8adfb895984b14f2941e8cb6ce in xen.git#stable-4.11 DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmGc2jgMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZlWUIAJ4bU9n2q9A4sqhiW0xJOCI4MIdwV2ym6xziP9iN e5sg0u3gdp94M1vLf//8h7julxLXgdJd10HWWpJkfRQcsfz3E1ul1O+mAsoHxJwI /qGl1Xis7AkDFjrPXthJUKh/DNgi8F1Rok7XDbfFznk34v4g6anh4JDfqJIUwIFQ l2s6qIOc2PjvmrJMXEboT1wEUADZNtChIqOL7Ibre9Zz6/mdr0FjPfPvLAqfvf9m aLaMElJMRx5iTEUG7qCYXUn8oKLbWNTv88yceudE7QZl3/zv/UnEL8nvBZWs/Gkx UbrC6wkNFUSpF/ngexvzsSE/SrfMYYaUPfIciyuxvuosGJY= =DmKh -END PGP SIGNATURE-
Xen Security Advisory 385 v2 (CVE-2021-28706) - guests may exceed their designated memory limit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28706 / XSA-385 version 2 guests may exceed their designated memory limit UPDATES IN VERSION 2 Add CVE numbers to patches. Public release. ISSUE DESCRIPTION = When a guest is permitted to have close to 16TiB of memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It would then only be the overflowed (and hence small) number which gets compared against the established upper bound. IMPACT == A guest may be able too allocate unbounded amounts of memory to itself. This may result in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are affected. On x86, only Xen builds with the BIGMEM configuration option enabled are affected. (This option is off by default.) Only hosts with more than 16 TiB of memory are affected. MITIGATION == Setting the maximum amount of memory a guest may allocate to strictly less than 1023 GiB will avoid the vulnerability. CREDITS === This issue was discovered by Julien Grall of Amazon. RESOLUTION == Applying the appropriate first attached patch resolves this specific issue. The second patch in addition documents altered support status of Xen on huge memory systems. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa385-?.patch xen-unstable xsa385-4.15.patchXen 4.15.x - 4.14.x xsa385-4.13.patchXen 4.13.x xsa385-4.12.patchXen 4.12.x $ sha256sum xsa385* b278902e293730a117605200910180bb842cf95db4bdedfd54b42b7314041d8c xsa385-1.patch 46a5ccfbb763b857f6cd0df46a9b7eed155b9de399ca4c68c9925faf4d1d9adb xsa385-2.patch 69ebe63dc7dca71f74260af19205a6387be56c7dc67b97fa7695ab1acd3c4da4 xsa385-4.12.patch 858eaad715e7cc62c4ab9784360f4ec77df70b2636b0755afe780d5c618cf9b4 xsa385-4.13.patch 831e86c3adfec532b1a48a0b967b7c58c37db3733aee8d78216eb9d535b34f12 xsa385-4.15.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change is recognizable by the affected guests. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmGc2jYMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZEd4IAMwrHHAqFvSHgZ8Uw+DzMeT54db9nowudP9i/kYy +KobbVlGkxwLAU3mvh5lRkOLYzoIonrcA99cajZQNIcOKt3Mfi/8qzGGUN+hWZvh 6EZo3m7+7vx9mhtAeDBUbjkcZBLiVyxRAWALMS67ScBEX9lZTvbyj9nGkdQJmmfR pKt98z2Da2uR9YF521KWobuPYC0AFXujYBoavaTQpU/M8SiM+Wp1A2Fc6ZG+9ZKo frMeqFbHvwj94Hbqpn6CoLu2d/XnykMvttuLlqCKTccQc3puHXdQRz14W8IxxGYx gqYaIShZCFw/bUCu8mYHroDUlELJI3PIWQ1nJxy02bd5+N0= =7E6A -END PGP SIGNATURE- xsa385-1.patch Description: Binary data xsa385-2.patch Description: Binary data xsa385-4.12.patch Description: Binary data xsa385-4.13.patch Description: Binary data xsa385-4.15.patch Description: Binary data
Xen Security Advisory 388 v3 (CVE-2021-28704,CVE-2021-28707,CVE-2021-28708) - PoD operations on misaligned GFNs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28704,CVE-2021-28707,CVE-2021-28708 / XSA-388 version 3 PoD operations on misaligned GFNs UPDATES IN VERSION 3 Correct affected versions range. Add CVE numbers to patches. Public release. ISSUE DESCRIPTION = x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEM_decrease_reservation (CVE-2021-28704) and XENMEM_populate_physmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEM_decrease_reservation can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708, patch 2). IMPACT == Malicious or buggy guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS == All Xen versions from 4.7 onwards are affected. Xen versions 4.6 and older are not affected. Only x86 HVM and PVH guests started in populate-on-demand mode can leverage the vulnerability. Populate-on-demand mode is activated when the guest's xl configuration file specifies a "maxmem" value which is larger than the "memory" value. MITIGATION == Not starting x86 HVM or PVH guests in populate-on-demand mode will avoid the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate pair if attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa388-?.patch xen-unstable xsa388-4.15-?.patch Xen 4.15.x xsa388-4.14-?.patch Xen 4.14.x - 4.12.x $ sha256sum xsa388* 43f6647e9f7d28d22eeb98680e116b301b0e29ef63ea65c9839a5aaebd449bc4 xsa388-1.patch 64b27a8c7c02036528e00a3070e27e873762d68f4ea1504e906aaf2ddc1c06be xsa388-2.patch 6917267482101a3f8f1d13905e14994344a0af81370c7a2b92275fb176b321a0 xsa388-4.14-1.patch d5886e046c69f34f98f7e1fc6ffcc36d92f8fc79242b9dc88412c39aa79b4ac3 xsa388-4.14-2.patch fbe6af409447edc2318940d7c4bc0861a236d40db037166608fc09fa57ef54b1 xsa388-4.15-1.patch c828d735aaa3f430ccef314bf27519cd6a5f4daaa79e1c493dc47e42ab09ec9f xsa388-4.15-2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change is recognizable by the affected guests. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmGc2jkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZROMIALJsptV0nV8H5/nCLUWld3mKjAeb/+N20ul9NEwn rUwIGGGzyrKZQdAljno+9y9o5pM8+BC+aTBwYhmxEWsHm1kodTD+YnJYf8uNW/CW uhTJp/ZB5EsWhTFHF7YoKbPG0on4KIsy0TgoUug7bv+l2zEny9gfknsj8jdp3qCy aFv1Bb2PzRh462qVHI3f27Ee8bn7GfErouuLppmDpCva19D3bhUXQ5PhxFB+oqsI bww4VKUo0nxZftYhpbInWm34dajEIXK7jy5Z/CUPgCj2sTOHHBv7+5JJdw0umn/A lJ2Ta1u03sdC9JWbat4qjvdVgK9L9vT+jWsfcwk02qq+XSU= =uSRt -END PGP SIGNATURE- xsa388-1.patch Description: Binary data xsa388-2.patch Description: Binary data xsa388-4.14-1.patch Des
Xen Security Advisory 393 v2 (CVE-2022-23033) - arm: guest_physmap_remove_page not removing the p2m mappings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-23033 / XSA-393 version 2 arm: guest_physmap_remove_page not removing the p2m mappings UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The functions to remove one or more entries from a guest p2m pagetable on Arm (p2m_remove_mapping, guest_physmap_remove_page, and p2m_set_entry with mfn set to INVALID_MFN) do not actually clear the pagetable entry if the entry doesn't have the valid bit set. It is possible to have a valid pagetable entry without the valid bit set when a guest operating system uses set/way cache maintenance instructions. For instance, a guest issuing a set/way cache maintenance instruction, then calling the XENMEM_decrease_reservation hypercall to give back memory pages to Xen, might be able to retain access to those pages even after Xen started reusing them for other purposes. IMPACT == A malicious guest may be able to access Xen and other domains' memory. This could cause information leaks, host or domain Denial of Service (DoS), and privilege escalations. VULNERABLE SYSTEMS ====== Xen version 4.12 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Dmytro Firsov of EPAM. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa393.patch xen-unstable - Xen 4.12.x $ sha256sum xsa393* ccd746687c6080ec00ba363477d8815bc648d957c21c47d3a5330be9251806a4 xsa393.meta 89e5d66c437bacbe344e72d15720c1dde98dd97fab7184c7a6ff32bb63d442dd xsa393.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmHv38oMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZfAcH/iXwGyTpGU7AIOGNGH1VYnn3FBAVBvT4etuPXO8o heX252xCZNh7M7qel/Db1aaAMpo2T2ypH02ZguKsojnoRAo4QrEjrnBGsCasfzqv HFd3nMlmksNlKI9xGPxt+Q6eNuoEHgu7i/7r3J2DgiC/Pa5Hw4SMF2eat7Er5zDL waDHFkiONa6LM/dtgZkkgps5d3B8cR4tXo3VDLzBC0pK3IysSLnacLy7FfvLg7c0 pc/qFvUXbsFjKVmG+EKu8VlCpkWONFP1FXC4pfM+rSjDdVhmc8FhFzOLzD6Tkptt MJhgOCMrO1Z//F07l0B9C9sxVi7K5mUDSWhonUQVPCWgl2s= =06Nb -END PGP SIGNATURE- xsa393.meta Description: Binary data xsa393.patch Description: Binary data
Xen Security Advisory 394 v3 (CVE-2022-23034) - A PV guest could DoS Xen while unmapping a grant
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-23034 / XSA-394 version 3 A PV guest could DoS Xen while unmapping a grant UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = To address XSA-380, reference counting was introduced for grant mappings for the case where a PV guest would have the IOMMU enabled. PV guests can request two forms of mappings. When both are in use for any individual mapping, unmapping of such a mapping can be requested in two steps. The reference count for such a mapping would then mistakenly be decremented twice. Underflow of the counters gets detected, resulting in the triggering of a hypervisor bug check. IMPACT == Malicious guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable in principle, if they have the XSA-380 fixes applied. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 PV guests with access to PCI devices can leverage the vulnerability. x86 HVM and PVH guests, as well as PV guests without access to PCI devices, cannot leverage the vulnerability. Additionally from Xen 4.13 onwards x86 PV guests can leverage this vulnerability only when being granted access to pages owned by another domain. MITIGATION == Not running PV guests will avoid the vulnerability. For Xen 4.12 and older not passing through PCI devices to PV guests will avoid the vulnerability. For Xen 4.13 and newer not enabling PCI device pass-through for PV guests will avoid the vulnerability. This can be achieved via omitting any "passthrough=..." and "pci=..." settings from xl guest configuration files, or by setting "passthrough=disabled" there. - From Xen 4.13 onwards, XSM SILO can be available as a security policy designed to permit guests to only be able to communicate with Dom0. Dom0 does not normally offer its pages for guests to map, which means the use of SILO mode normally mitigates the vulnerability. CREDITS === This issue was discovered by Julien Grall of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa394.patch xen-unstable - Xen 4.13.x xsa394-4.12.patch Xen 4.12.x $ sha256sum xsa394* 93f4d3b58d49ba239115753c9905b7c3720b438c48ef8fb701f15081aa317159 xsa394.meta f2a3420e8d3eb1cf728f90d3c352ace0d3c67f7933201ce9b784d63afaeaa179 xsa394.patch ee93797546ac9e82f98211366f9acc72b0d5ab7ef73840c2acd2bb1439ca xsa394-4.12.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigations described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change is recognizable by the affected guests. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmHv39IMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZfCYH/iZn73/JRTKI7B+9v2fW6v/k1IcVhpu+N4+TuRhh Al5igmiTJLU3LcHM/H2KScgtnSwEKfCyddY1Gt3MZ+5lBDwR8elRkPdqn+P7xfol 4D5NgnEJDAYUWwJZOFn0qWfqNDnDkAvuKpm1zmv8RE0Xmw6a74Fvbfvi8PCuN9CO zdippi5r5FlzFU7Q5MoWmOhmvVe3Fg7tGs4GXIyVUYkpDYyBGEWBo6rcoQ5aDvir g8T0P1Y8XKCVvYM9SOdKWENppam0uIh00Mm+QDjQNaXD4I3DCDXLXkT7OGImZglr MW8z5iNFjd0iXxFqTVBe1omxUhLC1xcB1fNySjd3zpt3RfA= =mIA+ -END PGP SIGNATURE- xsa394.meta Description: Binary data xsa394.patch Description: Binary data xsa394-4.12.patch Description: Binary data
Xen Security Advisory 395 v2 (CVE-2022-23035) - Insufficient cleanup of passed-through device IRQs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-23035 / XSA-395 version 2 Insufficient cleanup of passed-through device IRQs UPDATES IN VERSION 2 Adjust patch subject. Public release. ISSUE DESCRIPTION = The management of IRQs associated with physical devices exposed to x86 HVM guests involves an iterative operation in particular when cleaning up after the guest's use of the device. In the case where an interrupt is not quiescent yet at the time this cleanup gets invoked, the cleanup attempt may be scheduled to be retried. When multiple interrupts are involved, this scheduling of a retry may get erroneously skipped. At the same time pointers may get cleared (resulting in a de-reference of NULL) and freed (resulting in a use-after-free), while other code would continue to assume them to be valid. IMPACT == The precise impact is system specific, but would typically be a Denial of Service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ====== Xen versions 4.6 and later are vulnerable. Xen versions 4.5 and earlier are not vulnerable. Only x86 HVM guests with one or more passed-through physical devices using (together) multiple physical interupts can leverage the vulnerability. x86 PV guests cannot leverage the vulnerability. x86 HVM guests without passed-through devices or with a passed-through device using just a single physical interrupt also cannot leverage the vulnerability. Device pass-through is unsupported for x86 PVH guests and all Arm guests. MITIGATION == There is no mitigation (other than not passing through to x86 HVM guests PCI devices with, overall, more than a single physical interrupt). CREDITS === This issue was discovered by Julien Grall of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa395.patch xen-unstable - Xen 4.15.x xsa395-4.14.patch Xen 4.14.x - Xen 4.12.x $ sha256sum xsa395* f460be598b936bb5cfb9276787f2f21d90b029d1fe10dabd572ae50f84a1124d xsa395.meta 295b876c52cf5efe19150757275da3d154beb72ac2d7be267e16c9262e410de3 xsa395.patch 5697f3137e0a202744f31b1c6cbcfa459d8fa9b4b68be59561b78c40fe1233c5 xsa395-4.14.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmHv39QMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZhowIAIZYZq4efyEAP5rB3zX4yRel2GNz+2Dpjok4PExB uSOrPaH5dDILhNdVJNG48MckDe0dMDsn3OGr1I6lbxcV1TWR1JFrBQoxeUnwdiEf GjeTni0hhefan3IEEd5HUDInQgf9oI7fUcgEdVAoIV87BQdlK0ofjJ3TggSrr8jl pL5dmIh4OICD6YttR11Of1vhPY2WhZQb2xgSxzEQbDeY8k3JaRWy8mYwwxPD0HXn +hmLK59ZhkJd5Sk8AxttRUTEsl6nKESrUz3vv/vFInV5Go+35AElL//gQNgOOTAS nljLLtJdfHSuRy459Sw/lm4mwQ9zkfOFH6B+M6efSkHMyoE= =Iv+w -END PGP SIGNATURE- xsa395.meta Description: Binary data xsa395.patch Description: Binary data xsa395-4.14.patch Description: Binary data
Xen Security Advisory 425 v1 (CVE-2022-42330) - Guests can cause Xenstore crash via soft reset
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-42330 / XSA-425 Guests can cause Xenstore crash via soft reset ISSUE DESCRIPTION = When a guest issues a "Soft Reset" (e.g. for performing a kexec) the libxl based Xen toolstack will normally perform a XS_RELEASE Xenstore operation. Due to a bug in xenstored this can result in a crash of xenstored. Any other use of XS_RELEASE will have the same impact. IMPACT == A malicious guest could try to kexec until it hits the xenstored bug, resulting in the inability to perform any further domain administration like starting new guests, or adding/removing resources to or from any existing guest. VULNERABLE SYSTEMS ====== Only Xen version 4.17 is vulnerable. Systems running an older version of Xen are not vulnerable. All Xen systems using C xenstored are vulnerable. Systems using the OCaml variant of xenstored are not vulnerable. Systems running only PV guests (x86 only) are not vulnerable, as long as they are using a libxl based toolstack. MITIGATION == The problem can be avoided by either: - - using the OCaml xenstored variant - - explicitly configuring guests to NOT perform the "Soft Reset" action by adding: on_soft_reset="reboot" or similar to the guest's configuration. This will break kexec in the guest, though. NOTE REGARDING LACK OF EMBARGO == This issue was discussed in public already. RESOLUTION == Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa425.patch xen-unstable, Xen 4.17.x $ sha256sum xsa425* 49f322c955fe7857cc824bba80625e56f582fdf0a4b244f513b6750e15ba5e48 xsa425.patch $ -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmPRQroMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZEpsIAJmIVB2lvqT2Qdp0pPSoaJIxXxuGE320kVTWmudB F2WbRCxeubqoOC/MyHTLOujMix6wBHnbm1cMQo0r4Vah/KX34vPS3wYqDZQYZtES aEkOQ+214QLAS2futcT0gde9idKpShI9jjWSRwcH01a7V6tlwwidc4V0luUFV0iX EKHPJ89rbbCMP1fOq5B+C7UP8oyiHItNWPWPFBwtUeXKvFiPOoyUPCoTHG8CCYHG WiVbeaZab7x/9+WUwXJ6hZqZiVr6NqoaItOx9Nbw4yCHwJlAj2UfA9skmqtGbPbB vxhkbIgOeiWoPvZgTGQjzZLosWO5+y30Fv5QYIbjA2/1OSQ= =7kiM -END PGP SIGNATURE- xsa425.patch Description: Binary data
Xen Security Advisory 426 v1 (CVE-2022-27672) - x86: Cross-Thread Return Address Predictions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-27672 / XSA-426
x86: Cross-Thread Return Address Predictions
ISSUE DESCRIPTION
=
It has been discovered that on some AMD CPUs, the RAS (Return Address
Stack, also called RAP - Return Address Predictor - in some AMD
documentation, and RSB - Return Stack Buffer - in Intel terminology) is
dynamically partitioned between non-idle threads. This allows an
attacker to control speculative execution on the adjacent thread.
For more details, see:
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1045
IMPACT
==
An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.
VULNERABLE SYSTEMS
==
Only AMD CPUs are known to be potentially vulnerable. CPUs from other
hardware vendors are not believed to be impacted.
Only the Zen1 and Zen2 microarchitectures are believed to be potentially
vulnerable. Other microarchitectures are not believed to be vulnerable.
Only configurations with SMT activate are potentially vulnerable. If
SMT is disabled by the firmware, or at runtime with `smt=0` on Xen's
command line, then the platform is not vulnerable.
Xen 4.17 and later contains an optimisation, specifically:
c/s afab477fba3b ("x86/spec-ctrl: Skip RSB overwriting when safe to do so")
which in combination with disabling 32bit PV guests (either at compile
time with CONFIG_PV32=n, or at runtime with `pv=no-32` on the command
line) renders Xen vulnerable to attack from PV guests.
Note: multiple downstreams are known to have backported this
optimisation to older versions of Xen. Consult your software vendor
documentation.
MITIGATION
==
On otherwise-vulnerable configurations, the issue can be mitigated by
booting Xen with `spec-ctrl=rsb`, which will override the aforementioned
optimisation.
Alternatively, SMT can be disabled either in the firmware, or by booting
Xen with `smt=0`.
Alternatively, if 32bit PV guests are only runtime disabled in Xen, this
issue can also be mitigated by booting Xen with `pv=32` to enable
support 32bit PV guests. It is not necessary for a 32bit PV guest to
actually be running in order to mitigate the issue.
RESOLUTION
==
Applying the attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa426.patch xen-unstable - Xen 4.17
$ sha256sum xsa426*
425b1d8931e02852afec9fe3d9f1d009f6d8a33c6387b2e8b3896f374732d470 xsa426.patch
$
-BEGIN PGP SIGNATURE-
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmPrzJoMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZiqsIALrisP3l7ImoKe49Bmb1blNYmUv6UjYGdVF9acc9
++QYPLq4Mu+kJuIlgKnT21hj7BFczL4KSi8sVw/nLqU3x8R/ZJ6nxXLlCod6RqGw
4MYd6QmArx8a+hm3LC0288VEFVXFh0WTDA6PK15RkspiwcjsAZ4w7DA7cRk0FLP0
9KJMhSPOAj9wCDhvOckr7DnA+D6gOKjMH83NCL0rg6Xe8+Bv0qTVYe49FqAnbWwc
9RsYOKfRuZUci+Z+mALVRB97R7xvns5D9HnDvs55ADri506JWkxmdp1GvLtjezXV
3Zds6TOrr1i0RQGV9M6aouinrI+DQNrOFR8V6p98KYxAo+Y=
=T8Uh
-END PGP SIGNATURE-
xsa426.patch
Description: Binary data
Xen Security Advisory 426 v2 (CVE-2022-27672) - x86: Cross-Thread Return Address Predictions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-27672 / XSA-426
version 2
x86: Cross-Thread Return Address Predictions
UPDATES IN VERSION 2
Xen 4.16 is vulnerable too. The previous analysis of impacted versions
was incorrect.
The same patch is applicable to Xen 4.16, and the staging-4.16 branch
has already had the backport applied.
ISSUE DESCRIPTION
=
It has been discovered that on some AMD CPUs, the RAS (Return Address
Stack, also called RAP - Return Address Predictor - in some AMD
documentation, and RSB - Return Stack Buffer - in Intel terminology) is
dynamically partitioned between non-idle threads. This allows an
attacker to control speculative execution on the adjacent thread.
For more details, see:
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1045
IMPACT
==
An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.
VULNERABLE SYSTEMS
==
Only AMD CPUs are known to be potentially vulnerable. CPUs from other
hardware vendors are not believed to be impacted.
Only the Zen1 and Zen2 microarchitectures are believed to be potentially
vulnerable. Other microarchitectures are not believed to be vulnerable.
Only configurations with SMT activate are potentially vulnerable. If
SMT is disabled by the firmware, or at runtime with `smt=0` on Xen's
command line, then the platform is not vulnerable.
Xen 4.16 and later contains an optimisation, specifically:
c/s afab477fba3b ("x86/spec-ctrl: Skip RSB overwriting when safe to do so")
which in combination with disabling 32bit PV guests (either at compile
time with CONFIG_PV32=n, or at runtime with `pv=no-32` on the command
line) renders Xen vulnerable to attack from PV guests.
Note: multiple downstreams are known to have backported this
optimisation to older versions of Xen. Consult your software vendor
documentation.
MITIGATION
==
On otherwise-vulnerable configurations, the issue can be mitigated by
booting Xen with `spec-ctrl=rsb`, which will override the aforementioned
optimisation.
Alternatively, SMT can be disabled either in the firmware, or by booting
Xen with `smt=0`.
Alternatively, if 32bit PV guests are only runtime disabled in Xen, this
issue can also be mitigated by booting Xen with `pv=32` to enable
support 32bit PV guests. It is not necessary for a 32bit PV guest to
actually be running in order to mitigate the issue.
RESOLUTION
==
Applying the attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa426.patch xen-unstable - Xen 4.16
$ sha256sum xsa426*
425b1d8931e02852afec9fe3d9f1d009f6d8a33c6387b2e8b3896f374732d470 xsa426.patch
$
-BEGIN PGP SIGNATURE-
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmPuawUMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZW1UIAJ6tjOwbjPJigbSVVfyr5FRnIIYjzVBqkhL5ufvc
TQY6ZoPsEEkXzx+jJeVa3NveiegqNvIdK26exlp7n2NrrWCRWlrdGlp+/83TWfUA
gwxBzERTVBmi67+9razBYKzxKAwXO2zOHsvgSB2aCX43K+e9SvlKMny8Wp9j0Z99
SRGxzZ8D4I7kKnMMpQIGvp/rt5+k+Q2oxXmNHnIsnCGshF+Y+zK7VwlSEpFYE1ga
78XWYULa1qOEbaj+xsPtf9mMIiWfViwKkX7ZT/EPFBbFxGHSK/aeiQmWdNcFGI3D
6L7vfJIo1Xsw26ozja+C+m3cFPhNSYJDRj92oCKmLPl8iII=
=hFGs
-END PGP SIGNATURE-
xsa426.patch
Description: Binary data
Xen Security Advisory 404 v1 (CVE-2022-21123,CVE-2022-21124,CVE-2022-21166) - x86: MMIO Stale Data vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-21123,CVE-2022-21124,CVE-2022-21166 / XSA-404 x86: MMIO Stale Data vulnerabilities ISSUE DESCRIPTION = This issue is related to the SRBDS, TAA and MDS vulnerabilities. Please see: https://xenbits.xen.org/xsa/advisory-320.html (SRBDS) https://xenbits.xen.org/xsa/advisory-305.html (TAA) https://xenbits.xen.org/xsa/advisory-297.html (MDS) Please see Intel's whitepaper: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html IMPACT == An attacker might be able to directly read or infer data from other security contexts in the system. This can include data belonging to other VMs, or to Xen itself. The degree to which an attacker can obtain data depends on the CPU, and the system configuration. VULNERABLE SYSTEMS == Systems running all versions of Xen are affected. Only x86 processors are vulnerable. Processors from other manufacturers (e.g. ARM) are not believed to be vulnerable. Only Intel based processors are affected. Processors from other x86 manufacturers (e.g. AMD) are not believed to be vulnerable. Please consult the Intel Security Advisory for details on the affected processors and configurations. Per Xen's support statement, PCI passthrough should be to trusted domains because the overall system security depends on factors outside of Xen's control. As such, Xen, in a supported configuration, is not vulnerable to DRPW/SBDR. MITIGATION == All mitigations depend on functionality added in the IPU 2022.1 (May 2022) microcode release from Intel. Consult your dom0 OS vendor. To the best of the security team's understanding, the summary is as follows: Server CPUs (Xeon EP/EX, Scalable, and some Atom servers), excluding Xeon E3 (which use the client CPU design), are potentially vulnerable to DRPW (CVE-2022-21166). Client CPUs (inc Xeon E3) are, furthermore, potentially vulnerable to SBDR (CVE-2022-21123) and SBDS (CVE-2022-21125). SBDS only affects CPUs vulnerable to MDS. On these CPUs, there are previously undiscovered leakage channels. There is no change to the existing MDS mitigations. DRPW and SBDR only affects configurations where less privileged domains have MMIO mappings of buggy endpoints. Consult your hardware vendor. In configurations where less privileged domains have MMIO access to buggy endpoints, `spec-ctrl=unpriv-mmio` can be enabled which will cause Xen to mitigate cross-domain fill buffer leakage, and extend SRBDS protections to protect RNG data from leakage. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. The patches are still under review. An update will be sent once they are reviewed and the backports are done. xsa404/xsa404-?.patch xen-unstable $ sha256sum xsa404*/* 18b307c2cbbd08d568e9dcb2447901d94e22ff1e3945c3436173aa693f6456fb xsa404/xsa404-1.patch d6f193ad963396285e983aa1c18539f67222582711fc62105c21b71b3b53a97d xsa404/xsa404-2.patch d2c123ccdf5eb9f862d6e9cb0e59045ae18799a07db149c7d90e301ca20436aa xsa404/xsa404-3.patch $ NOTE CONCERNING CVE-2022-21127 / Update to SRBDS An issue was discovered with the SRBDS microcode mitigation. A microcode update was released as part of Intel's IPU 2022.1 in May 2022. Updating microcode is sufficient to fix the issue, with no extra actions required on Xen's behalf. Consult your dom0 OS vendor or OEM for updated microcode. NOTE CONCERNING CVE-2022-21180 / Undefined MMIO Hang A related issue was discovered. See: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/undefined-mmio-hang.html Xen is not vulnerable to UMH in supported configurations. The only mitigation to is avoid passing impacted devices through to untrusted guests. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmKo0Z0MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZc8cH/RFgxQ4L8OewWMxsuowpgLg8NVyYGFMBgttscBh+ ANpjRTnV4yQGpt9nNFDAcXT1c/fvWhypOiwadEtczRl5k/Q96JOKFdiAc1QR35Oj vmbCLgO20jQ/GdTzaqKUaGBwi8GLShJvH1zMPJ2KuXk5w5uFDhj2gEiB6Kdv9+9O 4FBxQkpDzll0gs5v16ien8btKhEuZj9lNtzXZw5j4+DJD69MvQqsRPVdEt+M17Ox XGYcpfpLeGUaIUPFTPZDcFIJnMvqPBQyt+2eaeR2ezW2ouNpxepCSPsEDlAmSZ/K uZA0ShyJD3pfCxjc8eztyF/4zajY5EvuEtWdUZC/3zVaUec= =4EdA -END PGP SIGNATURE- xsa404/xsa404-1.patch Description: Binary data xsa404/xsa404-2.patch Description: Binary data xsa404/xsa404-3.patch Description: Binary data
Xen Security Advisory 406 v3 (CVE-2022-33744) - Arm guests can cause Dom0 DoS via PV devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-33744 / XSA-406 version 3 Arm guests can cause Dom0 DoS via PV devices UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = When mapping pages of guests on Arm, dom0 is using an rbtree to keep track of the foreign mappings. Updating of that rbtree is not always done completely with the related lock held, resulting in a small race window, which can be used by unprivileged guests via PV devices to cause inconsistencies of the rbtree. These inconsistencies can lead to Denial of Service (DoS) of dom0, e.g. by causing crashes or the inability to perform further mappings of other guests' memory pages. IMPACT == A guest performing multiple I/Os of PV devices in parallel can cause DoS of dom0 and thus of the complete host. VULNERABLE SYSTEMS == Only Arm systems (32-bit and 64-bit) are vulnerable. Dom0 Linux versions 3.13 - 5.18 are vulnerable. X86 systems are not vulnerable. MITIGATION == There is no mitigation available. CREDITS === This issue was discovered by Oleksandr Tyshchenko of EPAM. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa406-linux.patch Linux 3.13 - 5.19-rc $ sha256sum xsa406* 7a789f564b3365cade6e95d549dbbd5a8b7b5e53d09bc5a463c77dfefd5a4182 xsa406-linux.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmLEFgEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZwJUIAJSrSYNMQE4jo1sJFKjEJ3cHy6CymbJC94JSm2Tf HzeMlwd7NQF3Sc2HSWQoCSI+0TiRb6bJpfZASsbL/E3b6zcm3+VxwS7HVUtvHXhN HJYRUMN9vckUkGwWDYbgveI7uie9P7gpjwi5CEXxQf4NO9Oloyk2J5bijktzbBN2 9FIZ7zFuiSRwGtr2WRaozCSzgg4EGiPRc5eMCFMP+K0P+oRvpkE52wWo/ZOPzW8T xocUIcvQK335ib04OCS3oqJZrRNwrvX6Vn+CifXac2WHR9tQ24VnTq1iYRrVD+5x kxpg4IuiNc2eD8lZCLnKEUDUj6LzWvgxKoxXgJFKXlESb0A= =57so -END PGP SIGNATURE- xsa406-linux.patch Description: Binary data
Xen Security Advisory 405 v3 (CVE-2022-33743) - network backend may cause Linux netfront to use freed SKBs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-33743 / XSA-405 version 3 network backend may cause Linux netfront to use freed SKBs UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = While adding logic to support XDP (eXpress Data Path), a code label was moved in a way allowing for SKBs having references (pointers) retained for further processing to nevertheless be freed. IMPACT == A misbehaving or malicious backend may cause a Denial of Service (DoS) in the guest. Information leaks or privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == Linux versions 5.9 - 5.18 are vulnerable. Linux versions 5.8 and earlier are not vulnerable. This vulnerability only increases the capability of an attacker in systems with less than fully privileged network backends (e.g. network driver domains). For systems where netback runs in dom0 (the default configuration), this vulnerability does not increase the capabilities of an attacker. MITIGATION == There is no mitigation available other than not using PV devices in case a backend is suspected to be potentially malicious. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa405-linux.patch Linux 5.9 - 5.19-rc $ sha256sum xsa405* 69716b78fbd996bce0414079bbb5f002029c5a82924aaae0db78a13c4b385f0a xsa405-linux.patch $ DEPLOYMENT DURING EMBARGO = Deployment of patches or mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because the patches need to be applied in the affected guests. Switching from PV to non-PV devices is observable by the guests and has usually a bad performance impact. Deployment is permitted only AFTER the embargo ends. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmLEFgAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZgG4H/3KYUQdJlSEq2AEmIZhh1HDdhj/9n9Wxm0eHEqEQ pXvflqbqb2glZpQyWcFPcY4oRRYvy58p9FIEi3PJD+52K/7h58XcTEZKDFP87z53 iqATbN4s/wHQ45xWAuIEHsmfLRtj3gIr4qviux3dtygKMjo6cZDX7Ethv6j0xdgc lEUfvisH+3ZXG+JOQbZyxmi6g1SGDf1TJQczXR1rJjIp/npTupfFO+4r+vpiypbI 6ytFrRwmqfzuO8Mz5Wqrda8Fkk3JYoYtJdBfd/hYNu5vBN0d4o82sbZpuzVgdRI4 H+R90MB1XpZJ/mSYEDBbEctbmTFfJrRvr9yGjtCi8ivvQ5I= =fMa/ -END PGP SIGNATURE- xsa405-linux.patch Description: Binary data
Xen Security Advisory 403 v3 (CVE-2022-26365,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742) - Linux disk/nic frontends data leaks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory
CVE-2022-26365,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742 / XSA-403
version 3
Linux disk/nic frontends data leaks
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
Linux Block and Network PV device frontends don't zero memory regions before
sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally
the granularity of the grant table doesn't allow sharing less than a 4K page,
leading to unrelated data residing in the same 4K page as data shared with a
backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
IMPACT
==
An untrusted backend can access data not intended to be shared. If such
mappings are made with write permissions the backend could also cause
malfunctions and/or crashes to consumers of contiguous data in the shared
pages.
VULNERABLE SYSTEMS
==
All Linux guests using PV devices are vulnerable in case potentially
malicious PV device backends are being used.
MITIGATION
==
There is no mitigation available other than not using PV devices in case
a backend is suspected to be potentially malicious.
CREDITS
===
The issue related to not zeroing memory areas used for shared communications
was discovered by Roger Pau Monné of Citrix.
The issue related to leaking contiguous data in granted pages was disclosed
publicly.
RESOLUTION
==
Applying the attached patches to Linux makes the disk and network frontends
capable of protecting themselves against potentially malicious backends. The
signaling of whether a frontend should consider a backend as potentially
malicious can be done from either the Linux kernel command line or the
toolstack.
Two different patches are provided for each Xen branch, but only the first
patch will be applied to the official Xen repository for each branch.
For the xen-unstable branch patch 1 introduces a new field to the disk and nic
configurations that allow signaling on a per-device basis whether the backend
should be trusted. This is an ABI incompatible change, and cannot be applied
to stable branches. Patch 2 introduces support to libxl for
libxl_{disk,nic}_backend_untrusted environment variable to be used in order to
set whether disk and network frontends should be trusted in the absence of a
per-device setting. Patch 2 is provided as a courtesy for users of stable
branches that might come to rely on this behavior.
For the stable branches (Xen 4.16.x - Xen 4.13.x) patch 1 introduces support to
libxl for libxl_{disk,nic}_backend_untrusted environment variable to be used in
order to set whether disk and network backends should be trusted. Patch 2
reverts patch 1 and instead provides the more fine grained per-device options
that break the libxl ABI.
Note that applying patch 2 to any of the stable releases will require a rebuild
of any consumers of the libxl library, as it introduces an ABI breakage and
hence won't be applied to the official repository stable branches. Users of
stable releases wanting to use the functionality provided by patch 2 will need
to apply it manually.
Regardless of the combinations of patches applied, in the absence of any
environment variable mentioned above backends will be trusted by default.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa403/xsa403-?.patch xen-unstable
xsa403/xsa403-4.16-?.patch Xen 4.16.x - Xen 4.15.x
xsa403/xsa403-4.14-?.patch Xen 4.14.x - Xen 4.13.x
xsa403/xsa403-linux-*.patch Linux 5.18
$ sha256sum xsa403*/*
f28624407a3f040456ef2c52a18d8dcf486274ea082335ea38c9791646f4989c
xsa403/xsa403-1.patch
e06451655775009ceaf460bbba65374c05203eed295ff43fc5fa32a8d390a94a
xsa403/xsa403-2.patch
5efb8af5ed5614f5e2e8d606a9debb3503cd9e114551525826fc5a7f9de91c02
xsa403/xsa403-4.14-1.patch
9ead8c6e4d694f3042c8d2fab4ea81619c4a9fc2aa7a0f485e9c873d927d283c
xsa403/xsa403-4.14-2.patch
ae778d5731ae663cca32d59ed9b1be51200b85c441771a9c6657c112e9550a15
xsa403/xsa403-4.16-1.patch
8ef7bd06f646fa72f22892d2b72ae44ff4e6c00d9817d52a71262be174862ee3
xsa403/xsa403-4.16-2.patch
8192d0c313448d7aa12c13d1632db3bd68835c19f60c237b87548d5c528852b0
xsa403/xsa403-linux-1.patch
4b288d3266f9396bedc7de823909aed4d1a89fe86b2edd1d625b0e32741688cf
xsa403/xsa403-linux-2.patch
dddf68625be516f0524fe7bb439272769cf7d612e15e00ac936bc047fd182f8a
xsa403/xsa403-linux-3.patch
4e38a50a0e5ec6e90d2fffef003f8eb93a68518f4636c15cd59568ddf1861988
xsa403/xsa403-linux-4.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only b
Xen Security Advisory 408 v2 (CVE-2022-33745) - insufficient TLB flush for x86 PV guests in shadow mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-33745 / XSA-408 version 2 insufficient TLB flush for x86 PV guests in shadow mode UPDATES IN VERSION 2 Added metadata Public release. ISSUE DESCRIPTION = For migration as well as to work around kernels unaware of L1TF (see XSA-273), PV guests may be run in shadow paging mode. To address XSA-401, code was moved inside a function in Xen. This code movement missed a variable changing meaning / value between old and new code positions. The now wrong use of the variable did lead to a wrong TLB flush condition, omitting flushes where such are necessary. IMPACT == The known (observed) impact would be a Denial of Service (DoS) affecting the entire host, due to running out of memory. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS == All versions of Xen with the XSA-401 fixes applied are vulnerable. Only x86 PV guests can trigger this vulnerability, and only when running in shadow mode. Shadow mode would be in use when migrating guests or as a workaround for XSA-273 (L1TF). MITIGATION == Not running x86 PV guests will avoid the vulnerability. CREDITS === This issue was discovered by Charles Arnold of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa408.patch xen-unstable - Xen 4.14.x xsa408-4.13.patch Xen 4.13.x $ sha256sum xsa408* 7349445d53b68bc8e2be2aea9fa20409a9b87e0d6b78fc2515093a65668444a0 xsa408.meta f49cb67842c7576f1d59b965331956a9fa1f529a8e2da3531d7ebc4eb3f079b3 xsa408.patch 26871efbd3f834dd4af4fbab6f2cb09a83c509e49894f025ee656071419ed995 xsa408-4.13.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmLfyP4MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZSkAIAM3XDzBdUXux7ONc9nztSMGPBdWosC5f0SycveSq adplJeShw50aFYLxpZzqfCBAX/Jh0ooF+7gHnjVMuKKkg8vu5SfBpSGRdmva6jpc qNXoNyIc21PdNH4PVCKDQnO8Dq8wPSCnPpMZbFwk2uz7QGN5BKU/GM6XQrmXA3wz 3XYIcVVR377MdDuR8UQKyCSAG0JPr6SiozygRFHykGjg9NABWZwGyod64C9xBAyu K8CGTx12bAJEVcqJbGAVSEU6J5iKdWjSLHwy43ZOcAFvfiCAlolBOPlfjJTllYdQ Yhv0wQtOwsIDjQU6vbUtMsckuNEmfMPTEkRHPOpp46dPuVk= =33sr -END PGP SIGNATURE- xsa408.meta Description: Binary data xsa408.patch Description: Binary data xsa408-4.13.patch Description: Binary data
Xen Security Advisory 408 v3 (CVE-2022-33745) - insufficient TLB flush for x86 PV guests in shadow mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-33745 / XSA-408 version 3 insufficient TLB flush for x86 PV guests in shadow mode UPDATES IN VERSION 3 Update hash for metadata file. ISSUE DESCRIPTION = For migration as well as to work around kernels unaware of L1TF (see XSA-273), PV guests may be run in shadow paging mode. To address XSA-401, code was moved inside a function in Xen. This code movement missed a variable changing meaning / value between old and new code positions. The now wrong use of the variable did lead to a wrong TLB flush condition, omitting flushes where such are necessary. IMPACT == The known (observed) impact would be a Denial of Service (DoS) affecting the entire host, due to running out of memory. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS == All versions of Xen with the XSA-401 fixes applied are vulnerable. Only x86 PV guests can trigger this vulnerability, and only when running in shadow mode. Shadow mode would be in use when migrating guests or as a workaround for XSA-273 (L1TF). MITIGATION == Not running x86 PV guests will avoid the vulnerability. CREDITS === This issue was discovered by Charles Arnold of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa408.patch xen-unstable - Xen 4.14.x xsa408-4.13.patch Xen 4.13.x $ sha256sum xsa408* 9411b563c71445d2c95e36aba9d71fa3b9341f0230e4b3e2549a63292df11669 xsa408.meta f49cb67842c7576f1d59b965331956a9fa1f529a8e2da3531d7ebc4eb3f079b3 xsa408.patch 26871efbd3f834dd4af4fbab6f2cb09a83c509e49894f025ee656071419ed995 xsa408-4.13.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmLgPzsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZT5cIAKtisZZvdcSolZ+RHFzAdVEP2lbEW2TyoG6oy0st kMsV/ZSabthow9PiUp48DoZOXSIh/7hn2qyXqx5X0VYjiWOISVRCldm5g4p0+tA/ GN6FztbRR1GargLkvtuWj38K9E7HIqfBRFLbtJD6X97NFSAPeNNZg8nqQPqwkhK+ yeGBjPPO5pTjNwsRt91A1qEttTPjbBpipEcit/qjqqCBxX6NT/pYSE5Ltn2OHm38 eYM25X901rJl0rPsyOeUN312FAL0bEunKVKJbiNcHVBZoR37YoJ5HE5trDxoxPrz XYJdR7gzcB028lbGU4jt9FVHdYCh0htWpdpdWci4A3DCH7U= =C02g -END PGP SIGNATURE- xsa408.meta Description: Binary data xsa408.patch Description: Binary data xsa408-4.13.patch Description: Binary data
Xen Security Advisory 428 v3 (CVE-2022-42333,CVE-2022-42334) - x86/HVM pinned cache attributes mis-handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-42333,CVE-2022-42334 / XSA-428 version 3 x86/HVM pinned cache attributes mis-handling UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = To allow cachability control for HVM guests with passed through devices, an interface exists to explicitly override defaults which would otherwise be put in place. While not exposed to the affected guests themselves, the interface specifically exists for domains controlling such guests. This interface may therefore be used by not fully privileged entities, e.g. qemu running deprivileged in Dom0 or qemu running in a so called stub-domain. With this exposure it is an issue that - the number of the such controlled regions was unbounded (CVE-2022-42333), - installation and removal of such regions was not properly serialized (CVE-2022-42334). IMPACT == Entities controlling HVM guests can run the host out of resources or stall execution of a physical CPU for effectively unbounded periods of time, resulting in a Denial of Servis (DoS) affecting the entire host. Crashes, information leaks, or elevation of privilege cannot be ruled out. VULNERABLE SYSTEMS == Xen versions 4.11 through 4.17 are vulnerable. Older versions contain the same functionality, but it is exposed there only via an interface which is subject to XSA-77's constraints. Only x86 systems are potentially vulnerable. Arm systems are not vulnerable. Only entities controlling HVM guests can leverage the vulnerability. These are device models running in either a stub domain or de-privileged in Dom0. MITIGATION == Running only PV or PVH guests will avoid the vulnerability. (Switching from a device model stub domain or a de-privileged device model to a fully privileged Dom0 device model does NOT mitigate this vulnerability. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". The security of a Xen system using stub domains is still better than with a qemu-dm running as a Dom0 process. Users and vendors of stub qemu dm systems should not change their configuration to use a Dom0 qemu process.) CREDITS === Aspects of this issue were discovered by Andrew Cooper of XenServer and Jan Beulich of SUSE. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa428-?.patch xen-unstable xsa428-4.17-?.patch Xen 4.17.x xsa428-4.16-?.patch Xen 4.16.x - 4.14.x $ sha256sum xsa428* a7bd8d4c1e8579aeda47564efdc960cac92472387ba57d7f7a6d5d79470ebd6f xsa428.meta 85a421d9123a56894124bed54731b8b6f2e86ad4e286871dee86efff519f4c68 xsa428-1.patch 3b691ca228592539a751ce5af69f31e09d9c477218d53af0602ac5f39f1e74d7 xsa428-2.patch da60e01a17f9073c83098d187c07bad3a868a6b7f97dbc538cb5ea5698c51b39 xsa428-4.16-1.patch 27718a7a86fd57624cd8500df83eb42ff3499670bc807c6555686c25e7f7b01a xsa428-4.16-2.patch da60e01a17f9073c83098d187c07bad3a868a6b7f97dbc538cb5ea5698c51b39 xsa428-4.17-1.patch 20d3b66da8fe06d7e92992218e519f4f9746791d4ba5610d84a335f38a824fcb xsa428-4.17-2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmQZlkwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZevEH/R0hCjoC/n2AJSr2dOU97c4bZmjeB5mTnWrOtOMA AZnP68nvEzQ7OYfI4ihl+wgtKUvyVXLOWaBH9lKL8CySxrCX1r3BILMGhtDKViV4 opnKOoy0Ejg3H68x5McPhdr+PkvXWTzoNqbkUYMbNTw7ktB4Ze0mbsmKoXDUiLru QZZ0XxtL4jc+d8GUM0k3Msy0p3lLYvIob8k6DWg7RdWxiIOxL43pKNvShgh7ZehN P0S/PknVLpoPKzKFzMWrzakhZYYsOWoNM9U7C0zEozX4qrnsyQp3o3mvW/8MrPA+ 5BKsIjSYxdleUzLSNks7Xn0nG+ki
