--- /dev/null
+From 341198eda723c8c1cddbb006a89ad9e362502ea2 Mon Sep 17 00:00:00 2001
+From: Leonid Iziumtsev <leonid.iziumtsev@gmail.com>
+Date: Tue, 15 Jan 2019 17:15:23 +0000
+Subject: dmaengine: imx-dma: fix wrong callback invoke
+
+From: Leonid Iziumtsev <leonid.iziumtsev@gmail.com>
+
+commit 341198eda723c8c1cddbb006a89ad9e362502ea2 upstream.
+
+Once the "ld_queue" list is not empty, next descriptor will migrate
+into "ld_active" list. The "desc" variable will be overwritten
+during that transition. And later the dmaengine_desc_get_callback_invoke()
+will use it as an argument. As result we invoke wrong callback.
+
+That behaviour was in place since:
+commit fcaaba6c7136 ("dmaengine: imx-dma: fix callback path in tasklet").
+But after commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job")
+things got worse, since possible delay between tasklet_schedule()
+from DMA irq handler and actual tasklet function execution got bigger.
+And that gave more time for new DMA request to be submitted and
+to be put into "ld_queue" list.
+
+It has been noticed that DMA issue is causing problems for "mxc-mmc"
+driver. While stressing the system with heavy network traffic and
+writing/reading to/from sd card simultaneously the timeout may happen:
+
+10013000.sdhci: mxcmci_watchdog: read time out (status = 0x30004900)
+
+That often lead to file system corruption.
+
+Signed-off-by: Leonid Iziumtsev <leonid.iziumtsev@gmail.com>
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/imx-dma.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/dma/imx-dma.c
++++ b/drivers/dma/imx-dma.c
+@@ -619,7 +619,7 @@ static void imxdma_tasklet(unsigned long
+ {
+ struct imxdma_channel *imxdmac = (void *)data;
+ struct imxdma_engine *imxdma = imxdmac->imxdma;
+- struct imxdma_desc *desc;
++ struct imxdma_desc *desc, *next_desc;
+ unsigned long flags;
+
+ spin_lock_irqsave(&imxdma->lock, flags);
+@@ -649,10 +649,10 @@ static void imxdma_tasklet(unsigned long
+ list_move_tail(imxdmac->ld_active.next, &imxdmac->ld_free);
+
+ if (!list_empty(&imxdmac->ld_queue)) {
+- desc = list_first_entry(&imxdmac->ld_queue, struct imxdma_desc,
+- node);
++ next_desc = list_first_entry(&imxdmac->ld_queue,
++ struct imxdma_desc, node);
+ list_move_tail(imxdmac->ld_queue.next, &imxdmac->ld_active);
+- if (imxdma_xfer_desc(desc) < 0)
++ if (imxdma_xfer_desc(next_desc) < 0)
+ dev_warn(imxdma->dev, "%s: channel: %d couldn't xfer desc\n",
+ __func__, imxdmac->channel);
+ }
--- /dev/null
+From ecec76885bcfe3294685dc363fd1273df0d5d65f Mon Sep 17 00:00:00 2001
+From: Peter Shier <pshier@google.com>
+Date: Thu, 11 Oct 2018 11:46:46 -0700
+Subject: KVM: nVMX: unconditionally cancel preemption timer in free_nested (CVE-2019-7221)
+
+From: Peter Shier <pshier@google.com>
+
+commit ecec76885bcfe3294685dc363fd1273df0d5d65f upstream.
+
+Bugzilla: 1671904
+
+There are multiple code paths where an hrtimer may have been started to
+emulate an L1 VMX preemption timer that can result in a call to free_nested
+without an intervening L2 exit where the hrtimer is normally
+cancelled. Unconditionally cancel in free_nested to cover all cases.
+
+Embargoed until Feb 7th 2019.
+
+Signed-off-by: Peter Shier <pshier@google.com>
+Reported-by: Jim Mattson <jmattson@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Reported-by: Felix Wilhelm <fwilhelm@google.com>
+Cc: stable@kernel.org
+Message-Id: <20181011184646.154065-1-pshier@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/vmx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -6965,6 +6965,7 @@ static void free_nested(struct vcpu_vmx
+ if (!vmx->nested.vmxon)
+ return;
+
++ hrtimer_cancel(&vmx->nested.preemption_timer);
+ vmx->nested.vmxon = false;
+ free_vpid(vmx->nested.vpid02);
+ nested_release_vmcs12(vmx);
--- /dev/null
+From 353c0956a618a07ba4bbe7ad00ff29fe70e8412a Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Tue, 29 Jan 2019 18:41:16 +0100
+Subject: KVM: x86: work around leak of uninitialized stack contents (CVE-2019-7222)
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit 353c0956a618a07ba4bbe7ad00ff29fe70e8412a upstream.
+
+Bugzilla: 1671930
+
+Emulation of certain instructions (VMXON, VMCLEAR, VMPTRLD, VMWRITE with
+memory operand, INVEPT, INVVPID) can incorrectly inject a page fault
+when passed an operand that points to an MMIO address. The page fault
+will use uninitialized kernel stack memory as the CR2 and error code.
+
+The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
+exit to userspace; however, it is not an easy fix, so for now just
+ensure that the error code and CR2 are zero.
+
+Embargoed until Feb 7th 2019.
+
+Reported-by: Felix Wilhelm <fwilhelm@google.com>
+Cc: stable@kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -4247,6 +4247,13 @@ int kvm_read_guest_virt(struct kvm_vcpu
+ {
+ u32 access = (kvm_x86_ops->get_cpl(vcpu) == 3) ? PFERR_USER_MASK : 0;
+
++ /*
++ * FIXME: this should call handle_emulation_failure if X86EMUL_IO_NEEDED
++ * is returned, but our callers are not ready for that and they blindly
++ * call kvm_inject_page_fault. Ensure that they at least do not leak
++ * uninitialized kernel stack memory into cr2 and error code.
++ */
++ memset(exception, 0, sizeof(*exception));
+ return kvm_read_guest_virt_helper(addr, val, bytes, vcpu, access,
+ exception);
+ }
--- /dev/null
+From 9dff0aa95a324e262ffb03f425d00e4751f3294e Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Thu, 10 Jan 2019 14:27:45 +0000
+Subject: perf/core: Don't WARN() for impossible ring-buffer sizes
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+commit 9dff0aa95a324e262ffb03f425d00e4751f3294e upstream.
+
+The perf tool uses /proc/sys/kernel/perf_event_mlock_kb to determine how
+large its ringbuffer mmap should be. This can be configured to arbitrary
+values, which can be larger than the maximum possible allocation from
+kmalloc.
+
+When this is configured to a suitably large value (e.g. thanks to the
+perf fuzzer), attempting to use perf record triggers a WARN_ON_ONCE() in
+__alloc_pages_nodemask():
+
+ WARNING: CPU: 2 PID: 5666 at mm/page_alloc.c:4511 __alloc_pages_nodemask+0x3f8/0xbc8
+
+Let's avoid this by checking that the requested allocation is possible
+before calling kzalloc.
+
+Reported-by: Julien Thierry <julien.thierry@arm.com>
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Julien Thierry <julien.thierry@arm.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20190110142745.25495-1-mark.rutland@arm.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/events/ring_buffer.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/events/ring_buffer.c
++++ b/kernel/events/ring_buffer.c
+@@ -637,6 +637,9 @@ struct ring_buffer *rb_alloc(int nr_page
+ size = sizeof(struct ring_buffer);
+ size += nr_pages * sizeof(void *);
+
++ if (order_base_2(size) >= MAX_ORDER)
++ goto fail;
++
+ rb = kzalloc(size, GFP_KERNEL);
+ if (!rb)
+ goto fail;
--- /dev/null
+From 489338a717a0dfbbd5a3fabccf172b78f0ac9015 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 22 Jan 2019 17:34:39 -0600
+Subject: perf tests evsel-tp-sched: Fix bitwise operator
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 489338a717a0dfbbd5a3fabccf172b78f0ac9015 upstream.
+
+Notice that the use of the bitwise OR operator '|' always leads to true
+in this particular case, which seems a bit suspicious due to the context
+in which this expression is being used.
+
+Fix this by using bitwise AND operator '&' instead.
+
+This bug was detected with the help of Coccinelle.
+
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Acked-by: Jiri Olsa <jolsa@kernel.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Fixes: 6a6cd11d4e57 ("perf test: Add test for the sched tracepoint format fields")
+Link: http://lkml.kernel.org/r/20190122233439.GA5868@embeddedor
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/tests/evsel-tp-sched.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/perf/tests/evsel-tp-sched.c
++++ b/tools/perf/tests/evsel-tp-sched.c
+@@ -16,7 +16,7 @@ static int perf_evsel__test_field(struct
+ return -1;
+ }
+
+- is_signed = !!(field->flags | FIELD_IS_SIGNED);
++ is_signed = !!(field->flags & FIELD_IS_SIGNED);
+ if (should_be_signed && !is_signed) {
+ pr_debug("%s: \"%s\" signedness(%d) is wrong, should be %d\n",
+ evsel->name, name, is_signed, should_be_signed);
--- /dev/null
+From 9e63a7894fd302082cf3627fe90844421a6cbe7f Mon Sep 17 00:00:00 2001
+From: Kan Liang <kan.liang@linux.intel.com>
+Date: Sun, 27 Jan 2019 06:53:14 -0800
+Subject: perf/x86/intel/uncore: Add Node ID mask
+
+From: Kan Liang <kan.liang@linux.intel.com>
+
+commit 9e63a7894fd302082cf3627fe90844421a6cbe7f upstream.
+
+Some PCI uncore PMUs cannot be registered on an 8-socket system (HPE
+Superdome Flex).
+
+To understand which Socket the PCI uncore PMUs belongs to, perf retrieves
+the local Node ID of the uncore device from CPUNODEID(0xC0) of the PCI
+configuration space, and the mapping between Socket ID and Node ID from
+GIDNIDMAP(0xD4). The Socket ID can be calculated accordingly.
+
+The local Node ID is only available at bit 2:0, but current code doesn't
+mask it. If a BIOS doesn't clear the rest of the bits, an incorrect Node ID
+will be fetched.
+
+Filter the Node ID by adding a mask.
+
+Reported-by: Song Liu <songliubraving@fb.com>
+Tested-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@vger.kernel.org> # v3.7+
+Fixes: 7c94ee2e0917 ("perf/x86: Add Intel Nehalem and Sandy Bridge-EP uncore support")
+Link: https://lkml.kernel.org/r/1548600794-33162-1-git-send-email-kan.liang@linux.intel.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
++++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
+@@ -1081,6 +1081,8 @@ static struct pci_driver snbep_uncore_pc
+ .id_table = snbep_uncore_pci_ids,
+ };
+
++#define NODE_ID_MASK 0x7
++
+ /*
+ * build pci bus to socket mapping
+ */
+@@ -1102,7 +1104,7 @@ static int snbep_pci2phy_map_init(int de
+ err = pci_read_config_dword(ubox_dev, 0x40, &config);
+ if (err)
+ break;
+- nodeid = config;
++ nodeid = config & NODE_ID_MASK;
+ /* get the Node ID mapping */
+ err = pci_read_config_dword(ubox_dev, 0x54, &config);
+ if (err)
--- /dev/null
+From 42caa0edabd6a0a392ec36a5f0943924e4954311 Mon Sep 17 00:00:00 2001
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+Date: Wed, 30 Jan 2019 16:42:12 -0800
+Subject: scsi: aic94xx: fix module loading
+
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+
+commit 42caa0edabd6a0a392ec36a5f0943924e4954311 upstream.
+
+The aic94xx driver is currently failing to load with errors like
+
+sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:03.0/0000:02:00.3/0000:07:02.0/revision'
+
+Because the PCI code had recently added a file named 'revision' to every
+PCI device. Fix this by renaming the aic94xx revision file to
+aic_revision. This is safe to do for us because as far as I can tell,
+there's nothing in userspace relying on the current aic94xx revision file
+so it can be renamed without breaking anything.
+
+Fixes: 702ed3be1b1b (PCI: Create revision file in sysfs)
+Cc: stable@vger.kernel.org
+Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/aic94xx/aic94xx_init.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/scsi/aic94xx/aic94xx_init.c
++++ b/drivers/scsi/aic94xx/aic94xx_init.c
+@@ -281,7 +281,7 @@ static ssize_t asd_show_dev_rev(struct d
+ return snprintf(buf, PAGE_SIZE, "%s\n",
+ asd_dev_rev[asd_ha->revision_id]);
+ }
+-static DEVICE_ATTR(revision, S_IRUGO, asd_show_dev_rev, NULL);
++static DEVICE_ATTR(aic_revision, S_IRUGO, asd_show_dev_rev, NULL);
+
+ static ssize_t asd_show_dev_bios_build(struct device *dev,
+ struct device_attribute *attr,char *buf)
+@@ -478,7 +478,7 @@ static int asd_create_dev_attrs(struct a
+ {
+ int err;
+
+- err = device_create_file(&asd_ha->pcidev->dev, &dev_attr_revision);
++ err = device_create_file(&asd_ha->pcidev->dev, &dev_attr_aic_revision);
+ if (err)
+ return err;
+
+@@ -500,13 +500,13 @@ err_update_bios:
+ err_biosb:
+ device_remove_file(&asd_ha->pcidev->dev, &dev_attr_bios_build);
+ err_rev:
+- device_remove_file(&asd_ha->pcidev->dev, &dev_attr_revision);
++ device_remove_file(&asd_ha->pcidev->dev, &dev_attr_aic_revision);
+ return err;
+ }
+
+ static void asd_remove_dev_attrs(struct asd_ha_struct *asd_ha)
+ {
+- device_remove_file(&asd_ha->pcidev->dev, &dev_attr_revision);
++ device_remove_file(&asd_ha->pcidev->dev, &dev_attr_aic_revision);
+ device_remove_file(&asd_ha->pcidev->dev, &dev_attr_bios_build);
+ device_remove_file(&asd_ha->pcidev->dev, &dev_attr_pcba_sn);
+ device_remove_file(&asd_ha->pcidev->dev, &dev_attr_update_bios);
fuse-call-pipe_buf_release-under-pipe-lock.patch
fuse-decrement-nr_writeback_temp-on-the-right-page.patch
fuse-handle-zero-sized-retrieve-correctly.patch
+dmaengine-imx-dma-fix-wrong-callback-invoke.patch
+usb-phy-am335x-fix-race-condition-in-_probe.patch
+usb-gadget-udc-net2272-fix-bitwise-and-boolean-operations.patch
+scsi-aic94xx-fix-module-loading.patch
+kvm-x86-work-around-leak-of-uninitialized-stack-contents-cve-2019-7222.patch
+kvm-nvmx-unconditionally-cancel-preemption-timer-in-free_nested-cve-2019-7221.patch
+perf-x86-intel-uncore-add-node-id-mask.patch
+x86-mce-initialize-mce.bank-in-the-case-of-a-fatal-error-in-mce_no_way_out.patch
+perf-core-don-t-warn-for-impossible-ring-buffer-sizes.patch
+perf-tests-evsel-tp-sched-fix-bitwise-operator.patch
--- /dev/null
+From 07c69f1148da7de3978686d3af9263325d9d60bd Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 22 Jan 2019 15:28:08 -0600
+Subject: usb: gadget: udc: net2272: Fix bitwise and boolean operations
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 07c69f1148da7de3978686d3af9263325d9d60bd upstream.
+
+(!x & y) strikes again.
+
+Fix bitwise and boolean operations by enclosing the expression:
+
+ intcsr & (1 << NET2272_PCI_IRQ)
+
+in parentheses, before applying the boolean operator '!'.
+
+Notice that this code has been there since 2011. So, it would
+be helpful if someone can double-check this.
+
+This issue was detected with the help of Coccinelle.
+
+Fixes: ceb80363b2ec ("USB: net2272: driver for PLX NET2272 USB device controller")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/udc/net2272.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/gadget/udc/net2272.c
++++ b/drivers/usb/gadget/udc/net2272.c
+@@ -2100,7 +2100,7 @@ static irqreturn_t net2272_irq(int irq,
+ #if defined(PLX_PCI_RDK2)
+ /* see if PCI int for us by checking irqstat */
+ intcsr = readl(dev->rdk2.fpga_base_addr + RDK2_IRQSTAT);
+- if (!intcsr & (1 << NET2272_PCI_IRQ)) {
++ if (!(intcsr & (1 << NET2272_PCI_IRQ))) {
+ spin_unlock(&dev->lock);
+ return IRQ_NONE;
+ }
--- /dev/null
+From a53469a68eb886e84dd8b69a1458a623d3591793 Mon Sep 17 00:00:00 2001
+From: Bin Liu <b-liu@ti.com>
+Date: Wed, 16 Jan 2019 11:54:07 -0600
+Subject: usb: phy: am335x: fix race condition in _probe
+
+From: Bin Liu <b-liu@ti.com>
+
+commit a53469a68eb886e84dd8b69a1458a623d3591793 upstream.
+
+power off the phy should be done before populate the phy. Otherwise,
+am335x_init() could be called by the phy owner to power on the phy first,
+then am335x_phy_probe() turns off the phy again without the caller knowing
+it.
+
+Fixes: 2fc711d76352 ("usb: phy: am335x: Enable USB remote wakeup using PHY wakeup")
+Cc: stable@vger.kernel.org # v3.18+
+Signed-off-by: Bin Liu <b-liu@ti.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/phy/phy-am335x.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/drivers/usb/phy/phy-am335x.c
++++ b/drivers/usb/phy/phy-am335x.c
+@@ -56,9 +56,6 @@ static int am335x_phy_probe(struct platf
+ if (ret)
+ return ret;
+
+- ret = usb_add_phy_dev(&am_phy->usb_phy_gen.phy);
+- if (ret)
+- return ret;
+ am_phy->usb_phy_gen.phy.init = am335x_init;
+ am_phy->usb_phy_gen.phy.shutdown = am335x_shutdown;
+
+@@ -77,7 +74,7 @@ static int am335x_phy_probe(struct platf
+ device_set_wakeup_enable(dev, false);
+ phy_ctrl_power(am_phy->phy_ctrl, am_phy->id, false);
+
+- return 0;
++ return usb_add_phy_dev(&am_phy->usb_phy_gen.phy);
+ }
+
+ static int am335x_phy_remove(struct platform_device *pdev)
--- /dev/null
+From d28af26faa0b1daf3c692603d46bc4687c16f19e Mon Sep 17 00:00:00 2001
+From: Tony Luck <tony.luck@intel.com>
+Date: Thu, 31 Jan 2019 16:33:41 -0800
+Subject: x86/MCE: Initialize mce.bank in the case of a fatal error in mce_no_way_out()
+
+From: Tony Luck <tony.luck@intel.com>
+
+commit d28af26faa0b1daf3c692603d46bc4687c16f19e upstream.
+
+Internal injection testing crashed with a console log that said:
+
+ mce: [Hardware Error]: CPU 7: Machine Check Exception: f Bank 0: bd80000000100134
+
+This caused a lot of head scratching because the MCACOD (bits 15:0) of
+that status is a signature from an L1 data cache error. But Linux says
+that it found it in "Bank 0", which on this model CPU only reports L1
+instruction cache errors.
+
+The answer was that Linux doesn't initialize "m->bank" in the case that
+it finds a fatal error in the mce_no_way_out() pre-scan of banks. If
+this was a local machine check, then this partially initialized struct
+mce is being passed to mce_panic().
+
+Fix is simple: just initialize m->bank in the case of a fatal error.
+
+Fixes: 40c36e2741d7 ("x86/mce: Fix incorrect "Machine check from unknown source" message")
+Signed-off-by: Tony Luck <tony.luck@intel.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vishal Verma <vishal.l.verma@intel.com>
+Cc: x86-ml <x86@kernel.org>
+Cc: stable@vger.kernel.org # v4.18 Note pre-v5.0 arch/x86/kernel/cpu/mce/core.c was called arch/x86/kernel/cpu/mcheck/mce.c
+Link: https://lkml.kernel.org/r/20190201003341.10638-1-tony.luck@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/mcheck/mce.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/cpu/mcheck/mce.c
++++ b/arch/x86/kernel/cpu/mcheck/mce.c
+@@ -670,6 +670,7 @@ static int mce_no_way_out(struct mce *m,
+ }
+
+ if (mce_severity(m, mca_cfg.tolerant, &tmp, true) >= MCE_PANIC_SEVERITY) {
++ m->bank = i;
+ *msg = tmp;
+ ret = 1;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
