From: Greg Kroah-Hartman Date: Sun, 28 Nov 2021 11:46:55 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v5.15.6~65 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1d73d10d267d05557cf52eee401aff355c96a937;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: xen-detect-uninitialized-xenbus-in-xenbus_init.patch xen-don-t-continue-xenstore-initialization-in-case-of-errors.patch --- diff --git a/queue-4.4/series b/queue-4.4/series index 633410d2d09..579993fedc9 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -6,3 +6,5 @@ usb-hub-fix-locking-issues-with-address0_mutex.patch binder-fix-test-regression-due-to-sender_euid-change.patch alsa-ctxfi-fix-out-of-range-access.patch staging-rtl8192e-fix-use-after-free-in-_rtl92e_pci_disconnect.patch +xen-don-t-continue-xenstore-initialization-in-case-of-errors.patch +xen-detect-uninitialized-xenbus-in-xenbus_init.patch diff --git a/queue-4.4/xen-detect-uninitialized-xenbus-in-xenbus_init.patch b/queue-4.4/xen-detect-uninitialized-xenbus-in-xenbus_init.patch new file mode 100644 index 00000000000..dad43e47987 --- /dev/null +++ b/queue-4.4/xen-detect-uninitialized-xenbus-in-xenbus_init.patch @@ -0,0 +1,68 @@ +From 36e8f60f0867d3b70d398d653c17108459a04efe Mon Sep 17 00:00:00 2001 +From: Stefano Stabellini +Date: Tue, 23 Nov 2021 13:07:48 -0800 +Subject: xen: detect uninitialized xenbus in xenbus_init + +From: Stefano Stabellini + +commit 36e8f60f0867d3b70d398d653c17108459a04efe upstream. + +If the xenstore page hasn't been allocated properly, reading the value +of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return +error. Instead, it will succeed and return zero. Instead of attempting +to xen_remap a bad guest physical address, detect this condition and +return early. + +Note that although a guest physical address of zero for +HVM_PARAM_STORE_PFN is theoretically possible, it is not a good choice +and zero has never been validly used in that capacity. + +Also recognize all bits set as an invalid value. + +For 32-bit Linux, any pfn above ULONG_MAX would get truncated. Pfns +above ULONG_MAX should never be passed by the Xen tools to HVM guests +anyway, so check for this condition and return early. + +Cc: stable@vger.kernel.org +Signed-off-by: Stefano Stabellini +Reviewed-by: Juergen Gross +Reviewed-by: Jan Beulich +Link: https://lore.kernel.org/r/20211123210748.1910236-1-sstabellini@kernel.org +Signed-off-by: Boris Ostrovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/xen/xenbus/xenbus_probe.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +--- a/drivers/xen/xenbus/xenbus_probe.c ++++ b/drivers/xen/xenbus/xenbus_probe.c +@@ -804,6 +804,29 @@ static int __init xenbus_init(void) + err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v); + if (err) + goto out_error; ++ /* ++ * Uninitialized hvm_params are zero and return no error. ++ * Although it is theoretically possible to have ++ * HVM_PARAM_STORE_PFN set to zero on purpose, in reality it is ++ * not zero when valid. If zero, it means that Xenstore hasn't ++ * been properly initialized. Instead of attempting to map a ++ * wrong guest physical address return error. ++ * ++ * Also recognize all bits set as an invalid value. ++ */ ++ if (!v || !~v) { ++ err = -ENOENT; ++ goto out_error; ++ } ++ /* Avoid truncation on 32-bit. */ ++#if BITS_PER_LONG == 32 ++ if (v > ULONG_MAX) { ++ pr_err("%s: cannot handle HVM_PARAM_STORE_PFN=%llx > ULONG_MAX\n", ++ __func__, v); ++ err = -EINVAL; ++ goto out_error; ++ } ++#endif + xen_store_gfn = (unsigned long)v; + xen_store_interface = + xen_remap(xen_store_gfn << XEN_PAGE_SHIFT, diff --git a/queue-4.4/xen-don-t-continue-xenstore-initialization-in-case-of-errors.patch b/queue-4.4/xen-don-t-continue-xenstore-initialization-in-case-of-errors.patch new file mode 100644 index 00000000000..f24517f3b81 --- /dev/null +++ b/queue-4.4/xen-don-t-continue-xenstore-initialization-in-case-of-errors.patch @@ -0,0 +1,57 @@ +From 08f6c2b09ebd4b326dbe96d13f94fee8f9814c78 Mon Sep 17 00:00:00 2001 +From: Stefano Stabellini +Date: Mon, 15 Nov 2021 14:27:19 -0800 +Subject: xen: don't continue xenstore initialization in case of errors + +From: Stefano Stabellini + +commit 08f6c2b09ebd4b326dbe96d13f94fee8f9814c78 upstream. + +In case of errors in xenbus_init (e.g. missing xen_store_gfn parameter), +we goto out_error but we forget to reset xen_store_domain_type to +XS_UNKNOWN. As a consequence xenbus_probe_initcall and other initcalls +will still try to initialize xenstore resulting into a crash at boot. + +[ 2.479830] Call trace: +[ 2.482314] xb_init_comms+0x18/0x150 +[ 2.486354] xs_init+0x34/0x138 +[ 2.489786] xenbus_probe+0x4c/0x70 +[ 2.498432] xenbus_probe_initcall+0x2c/0x7c +[ 2.503944] do_one_initcall+0x54/0x1b8 +[ 2.507358] kernel_init_freeable+0x1ac/0x210 +[ 2.511617] kernel_init+0x28/0x130 +[ 2.516112] ret_from_fork+0x10/0x20 + +Cc: +Cc: jbeulich@suse.com +Signed-off-by: Stefano Stabellini +Link: https://lore.kernel.org/r/20211115222719.2558207-1-sstabellini@kernel.org +Reviewed-by: Jan Beulich +Signed-off-by: Boris Ostrovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/xen/xenbus/xenbus_probe.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/xen/xenbus/xenbus_probe.c ++++ b/drivers/xen/xenbus/xenbus_probe.c +@@ -764,7 +764,7 @@ static struct notifier_block xenbus_resu + + static int __init xenbus_init(void) + { +- int err = 0; ++ int err; + uint64_t v = 0; + xen_store_domain_type = XS_UNKNOWN; + +@@ -832,8 +832,10 @@ static int __init xenbus_init(void) + */ + proc_mkdir("xen", NULL); + #endif ++ return 0; + + out_error: ++ xen_store_domain_type = XS_UNKNOWN; + return err; + } +