From be3c16d1cb87c4698fbb44a42dc93f5d54111e30 Mon Sep 17 00:00:00 2001 From: Ariadne Conill Date: Wed, 8 Sep 2021 13:19:46 -0600 Subject: [PATCH] main/xen: add mitigation for XSA-384 (CVE-2021-28701) --- main/xen/APKBUILD | 9 +++-- main/xen/xsa384.patch | 81 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 87 insertions(+), 3 deletions(-) create mode 100644 main/xen/xsa384.patch diff --git a/main/xen/APKBUILD b/main/xen/APKBUILD index c79b1858085..8d32049303a 100644 --- a/main/xen/APKBUILD +++ b/main/xen/APKBUILD @@ -2,7 +2,7 @@ # Maintainer: Natanael Copa pkgname=xen pkgver=4.15.0 -pkgrel=2 +pkgrel=3 pkgdesc="Xen hypervisor" url="https://www.xenproject.org/" arch="x86_64 armhf aarch64" # enable armv7 when builds with gcc8 @@ -254,11 +254,12 @@ options="!strip" # - CVE-2021-28694 XSA-378 # - CVE-2021-28695 XSA-378 # - CVE-2021-28696 XSA-378 -# - CVE-2021-28967 XSA-379 +# - CVE-2021-28697 XSA-379 # - CVE-2021-28698 XSA-380 # - CVE-2021-28699 XSA-382 # - CVE-2021-28700 XSA-383 - +# 4.15.0-r3: +# - CVE-2021-28701 XSA-384 case "$CARCH" in x86*) @@ -350,6 +351,7 @@ source="https://downloads.xenproject.org/release/xen/$pkgver/xen-$pkgver.tar.gz xsa382.patch xsa383.patch + xsa384.patch xenstored.initd xenstored.confd @@ -615,6 +617,7 @@ d2d7096037f77b52b2c6144bda3a744f6edab9f72cabbaadb1751733c398278dbaace925f393bd96 c3aa4f37ebdbd35a59d5b889b65bcb18f5c7f15c07af335b4093a70ba84d674588eba63b18401b4f537486f437bd0495f6866bf16a527352ac6169deb70d2fa6 xsa380-3.patch 6c5e3388fcfb0dcae30d5f315bf95d263c82519d2cbf2a8a88d280b5b0b1c1ed4cce7a1a85fabbf57c785ad9dc23e8e5e4773c631c00e036aada604ff8e7fa03 xsa382.patch d5106df26e6c4512d88ea6748c403117a2b61cb40f6d6c08a76f160352b79f94dd67cbb3419a33f2c6cfc7bbd644baed0498e366a6bf00d8031df728a47f36ea xsa383.patch +fe14ee4e28001e28ab0c3c0eca56d00d4d6e95879eec1f81f780d783d3845a4dd1dcd38449b2b7085e9aad88f0b95c59eebb52d8b5cf868012ff410fe32b9870 xsa384.patch a8dda349cab62febf2ef506eb26d2ba494a649b1c37206519ae23f02a36f600b19996bb8a148e5f21a240ec53ecfcf971a07686b9ddcdad417563fdf39b2215f xenstored.initd 093f7fbd43faf0a16a226486a0776bade5dc1681d281c5946a3191c32d74f9699c6bf5d0ab8de9d1195a2461165d1660788e92a3156c9b3c7054d7b2d52d7ff0 xenstored.confd 1dd04f4bf1890771aa7eef0b6e46f7139487da0907d28dcdbef9fbe335dcf731ca391cfcb175dd82924f637a308de00a69ae981f67348c34f04489ec5e5dc3b7 xenconsoled.initd diff --git a/main/xen/xsa384.patch b/main/xen/xsa384.patch new file mode 100644 index 00000000000..4f155ac879b --- /dev/null +++ b/main/xen/xsa384.patch @@ -0,0 +1,81 @@ +From: Jan Beulich +Subject: gnttab: deal with status frame mapping race + +Once gnttab_map_frame() drops the grant table lock, the MFN it reports +back to its caller is free to other manipulation. In particular +gnttab_unpopulate_status_frames() might free it, by a racing request on +another CPU, thus resulting in a reference to a deallocated page getting +added to a domain's P2M. + +Obtain a page reference in gnttab_map_frame() to prevent freeing of the +page until xenmem_add_to_physmap_one() has actually completed its acting +on the page. Do so uniformly, even if only strictly required for v2 +status pages, to avoid extra conditionals (which then would all need to +be kept in sync going forward). + +This is CVE-2021-28701 / XSA-384. + +Reported-by: Julien Grall +Signed-off-by: Jan Beulich +Reviewed-by: Julien Grall +--- +v2: Pull get_page() earlier and fold if()s. + +--- a/xen/arch/arm/mm.c ++++ b/xen/arch/arm/mm.c +@@ -1420,6 +1420,8 @@ int xenmem_add_to_physmap_one( + if ( rc ) + return rc; + ++ /* Need to take care of the reference obtained in gnttab_map_frame(). */ ++ page = mfn_to_page(mfn); + t = p2m_ram_rw; + + break; +@@ -1487,9 +1489,12 @@ int xenmem_add_to_physmap_one( + /* Map at new location. */ + rc = guest_physmap_add_entry(d, gfn, mfn, 0, t); + +- /* If we fail to add the mapping, we need to drop the reference we +- * took earlier on foreign pages */ +- if ( rc && space == XENMAPSPACE_gmfn_foreign ) ++ /* ++ * For XENMAPSPACE_gmfn_foreign if we failed to add the mapping, we need ++ * to drop the reference we took earlier. In all other cases we need to ++ * drop any reference we took earlier (perhaps indirectly). ++ */ ++ if ( space == XENMAPSPACE_gmfn_foreign ? rc : page != NULL ) + { + ASSERT(page != NULL); + put_page(page); +--- a/xen/arch/x86/mm/p2m.c ++++ b/xen/arch/x86/mm/p2m.c +@@ -2726,6 +2726,8 @@ int xenmem_add_to_physmap_one( + rc = gnttab_map_frame(d, idx, gpfn, &mfn); + if ( rc ) + return rc; ++ /* Need to take care of the reference obtained in gnttab_map_frame(). */ ++ page = mfn_to_page(mfn); + break; + + case XENMAPSPACE_gmfn: +--- a/xen/common/grant_table.c ++++ b/xen/common/grant_table.c +@@ -4097,7 +4097,16 @@ int gnttab_map_frame(struct domain *d, u + } + + if ( !rc ) +- gnttab_set_frame_gfn(gt, status, idx, gfn); ++ { ++ /* ++ * Make sure gnttab_unpopulate_status_frames() won't (successfully) ++ * free the page until our caller has completed its operation. ++ */ ++ if ( get_page(mfn_to_page(*mfn), d) ) ++ gnttab_set_frame_gfn(gt, status, idx, gfn); ++ else ++ rc = -EBUSY; ++ } + + grant_write_unlock(gt); +