Headline
CVE-2022-26363
x86 pv: Insufficient care with non-coherent mappings T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Xen maintains a type reference count for pages, in addition to a regular reference count. This scheme is used to maintain invariants required for Xen’s safety, e.g. PV guests may not have direct writeable access to pagetables; updates need auditing by Xen. Unfortunately, Xen’s safety logic doesn’t account for CPU-induced cache non-coherency; cases where the CPU can cause the content of the cache to be different to the content in main memory. In such cases, Xen’s safety logic can incorrectly conclude that the contents of a page is safe.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2022-26363,CVE-2022-26364 / XSA-402 version 4 x86 pv: Insufficient care with non-coherent mappings UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= Xen maintains a type reference count for pages, in addition to a regular reference count. This scheme is used to maintain invariants required for Xen’s safety, e.g. PV guests may not have direct writeable access to pagetables; updates need auditing by Xen. Unfortunately, Xen’s safety logic doesn’t account for CPU-induced cache non-coherency; cases where the CPU can cause the content of the cache to be different to the content in main memory. In such cases, Xen’s safety logic can incorrectly conclude that the contents of a page is safe. IMPACT ====== Malicious x86 PV guest administrators can escalate privilege so as to control the whole system. VULNERABLE SYSTEMS ================== All versions of Xen are vulnerable. Only x86 PV guests can trigger this vulnerability. Only x86 PV guests configured with access to devices (e.g. PCI Passthrough) can trigger the vulnerability. Only CPUs which can issue non-coherent memory accesses are impacted. CPUs which enumerate the SelfSnoop feature are not impacted, except as noted in errata. Therefore, we believe that Xen running on Intel IvyBridge or later CPUs is not impacted by the vulnerability. MITIGATION ========== Not passing devices through to untrusted x86 PV guests will avoid the vulnerability. CREDITS ======= This issue was discovered by Jann Horn of Google Project Zero. 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. Furthermore, the XSA-402 patches depend logically on the XSA-401 patches, and will not function safely without XSA-401 in place first. xsa402/xsa402-?.patch xen-unstable xsa402/xsa402-4.16-?.patch Xen 4.16.x xsa402/xsa402-4.15-?.patch Xen 4.15.x xsa402/xsa402-4.14-?.patch Xen 4.14.x xsa402/xsa402-4.13-?.patch Xen 4.13.x $ sha256sum xsa402* xsa402*/* 3572a7bf70f372707705eec7e24ec6737d41dde906d82b4197597480df557b0c xsa402.meta ce956e3b24b34b10034d6cc219f616e96e5b7b3a391f6d9a97d96694579e86b3 xsa402/xsa402-1.patch 8faaae88b7d88a3ef66ebd9db7d5fbfa600ab1216b38954a7a8b44822a32b87e xsa402/xsa402-2.patch 344c76e842e830ef209427359d2b566d6b54f8862c16662ca628c459680614d7 xsa402/xsa402-3.patch 210e8312f351f1b26b58e5f24479381371ddfbae4b1d3b7233a9ed909a3d08cd xsa402/xsa402-4.13-1.patch 5d9e6cb667d47f58f1b85c02844510673f9bfa5a94a74847bfe641bc9722dc67 xsa402/xsa402-4.13-2.patch 176bbd997d163cfb17811065e084ee118ba272e02302c0237dcfeca7d261943d xsa402/xsa402-4.13-3.patch 0ee1adac14c185c3b928f8384c6f5749ecf1c028eb65e17ad54de5be0773b40b xsa402/xsa402-4.13-4.patch 366a79734861535818c54e3d831c7349de11fbd761ee04ced712590e50a149ed xsa402/xsa402-4.13-5.patch 487227003630a70a640e434c6b0125f73c8d7affc9c90297de737a29a0cf0c7e xsa402/xsa402-4.14-1.patch 328dd4090ecb6bd13696a9a69d098476d14ccde4d78e0127c2512569c73aa01a xsa402/xsa402-4.14-2.patch 739263e622620e95c03118d3ea9d4f96ea3ce83d17ae6d06ca596cbe3d7c6035 xsa402/xsa402-4.14-3.patch f35a7c0282efe0271517fe6407f2d36f97455710041fa3bce72a61bc3733b556 xsa402/xsa402-4.14-4.patch ba4b84e95fbad023c1db21b677b166e09a4a2c0c4346ecb4612a32ee97f37efe xsa402/xsa402-4.14-5.patch ccdcbebcef9b84dce82c95f6faaa85f73f137c47c54aa891ee350e90cf1e8ceb xsa402/xsa402-4.15-1.patch 51d6875b097ba9913620e827cc1d634e6d3506fb6ab8ab7ac763e46634d7b67c xsa402/xsa402-4.15-2.patch 58b02bd665366c235534c58bc0f040863f3b1083551541c2b6de090c5d0caf6c xsa402/xsa402-4.15-3.patch 457cb2be1425948589cd0b7084087f6b995df29af289c10f9e9011df6f704cc0 xsa402/xsa402-4.15-4.patch 808cb71f43ab64ac6e992ffc081790292e014b7476304502caaee0f2d8e92b6d xsa402/xsa402-4.15-5.patch d90732dd1ef85c6d33471f83a707245e4bff3b737110ba4b8533c549b06175cc xsa402/xsa402-4.16-1.patch f68ad7dd8f68f688bb2f42664af8c7eeecc4888b84afe8e102e96518c22ceb2c xsa402/xsa402-4.16-2.patch 96f0c356281c59cc90894c0160121469096c3076cc4e1b52e81a521da10e9d76 xsa402/xsa402-4.16-3.patch 27aeb50651bfde461b84c98a897062e261b9ac84b6e07e9afbaae4c20c61a963 xsa402/xsa402-4.16-4.patch d65c84f2cf1f75d96c1853ffeeb8eed793e6382d21795af04871ead07f6b330c xsa402/xsa402-4.16-5.patch 5b472eda637ff59b0b7dff85a7869d7197f728b581581ce97b1617c2dcb62397 xsa402/xsa402-4.patch 15741042b7e6c04deff2edcbd21f1c4649d58790919fa18d4b131b53d68a124f xsa402/xsa402-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. But: deployment of the mitigation (i.e., switching guests from passed-through devices to virtual devices) is *not* permitted during the embargo, as it could be seen by an attacker and potentially give them a hint about the nature of the vulnerability. Futhermore, 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/4UyVfoK9kFAmKh4lkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZWi0H/3qjj6TwK57IN/QXxMxnPf/Z8w1C4J64dHXXksXz epUV7NAUMhZMiL1TDRXORLCcUEC9ErwBb3xdz+rSy/3oyqVNL2vERu7LtXKriIgi WZYvk/19QzBNVTrGUbXmLFER/0hGo6r3wW3VPhziAoTc71f2PW4wIWbvGOzvHpSU PuRhScXNMdJsu6dh5mNahqQE2nxRSOY/B9D8KDZTCJ4GwMKqZGuwRu5FuoHhXDa/ iOy4kUt6SOJ46L7Za1ULdYe6wdYWzJJtVaoojgjU/gqwtT3uXLa3eqsUqXjGynxj iGGOMFTypAMhMXqEgKzUEbJOYvvaLmC/D/bbVZ7U80Nya18= =bGG4 -----END PGP SIGNATURE-----
Related news
Gentoo Linux Security Advisory 202208-23 - Multiple vulnerabilities have been discovered in Xen, the worst of which could result in remote code execution (guest sandbox escape). Versions less than 4.15.3 are affected.
On CPUs without SELFSNOOP support, a Xen PV domain that has access to a PCI device (which grants the domain the ability to set arbitrary cache attributes on all its pages) can trick Xen into validating an L2 pagetable that contains a cacheline that is marked as clean in the cache but actually differs from main memory. After the pagetable has been validated, an attacker can flush the "clean" cacheline, such that on the next load, unvalidated data from main memory shows up in the pagetable.