]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 28 Nov 2021 11:46:55 +0000 (12:46 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 28 Nov 2021 11:46:55 +0000 (12:46 +0100)
added patches:
xen-detect-uninitialized-xenbus-in-xenbus_init.patch
xen-don-t-continue-xenstore-initialization-in-case-of-errors.patch

queue-4.4/series
queue-4.4/xen-detect-uninitialized-xenbus-in-xenbus_init.patch [new file with mode: 0644]
queue-4.4/xen-don-t-continue-xenstore-initialization-in-case-of-errors.patch [new file with mode: 0644]

index 633410d2d0918575a287789c27040aa1b4a0c9e0..579993fedc957ff8286a24262af2e71df065a129 100644 (file)
@@ -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 (file)
index 0000000..dad43e4
--- /dev/null
@@ -0,0 +1,68 @@
+From 36e8f60f0867d3b70d398d653c17108459a04efe Mon Sep 17 00:00:00 2001
+From: Stefano Stabellini <stefano.stabellini@xilinx.com>
+Date: Tue, 23 Nov 2021 13:07:48 -0800
+Subject: xen: detect uninitialized xenbus in xenbus_init
+
+From: Stefano Stabellini <stefano.stabellini@xilinx.com>
+
+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 <stefano.stabellini@xilinx.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Reviewed-by: Jan Beulich <jbeulich@suse.com>
+Link: https://lore.kernel.org/r/20211123210748.1910236-1-sstabellini@kernel.org
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..f24517f
--- /dev/null
@@ -0,0 +1,57 @@
+From 08f6c2b09ebd4b326dbe96d13f94fee8f9814c78 Mon Sep 17 00:00:00 2001
+From: Stefano Stabellini <stefano.stabellini@xilinx.com>
+Date: Mon, 15 Nov 2021 14:27:19 -0800
+Subject: xen: don't continue xenstore initialization in case of errors
+
+From: Stefano Stabellini <stefano.stabellini@xilinx.com>
+
+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: <Stable@vger.kernel.org>
+Cc: jbeulich@suse.com
+Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
+Link: https://lore.kernel.org/r/20211115222719.2558207-1-sstabellini@kernel.org
+Reviewed-by: Jan Beulich <jbeulich@suse.com>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }