--- /dev/null
+From cc7a0bb058b85ea03db87169c60c7cfdd5d34678 Mon Sep 17 00:00:00 2001
+From: Tyrel Datwyler <tyreld@linux.ibm.com>
+Date: Mon, 15 Mar 2021 15:48:21 -0600
+Subject: PCI: rpadlpar: Fix potential drc_name corruption in store functions
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tyrel Datwyler <tyreld@linux.ibm.com>
+
+commit cc7a0bb058b85ea03db87169c60c7cfdd5d34678 upstream.
+
+Both add_slot_store() and remove_slot_store() try to fix up the
+drc_name copied from the store buffer by placing a NUL terminator at
+nbyte + 1 or in place of a '\n' if present. However, the static buffer
+that we copy the drc_name data into is not zeroed and can contain
+anything past the n-th byte.
+
+This is problematic if a '\n' byte appears in that buffer after nbytes
+and the string copied into the store buffer was not NUL terminated to
+start with as the strchr() search for a '\n' byte will mark this
+incorrectly as the end of the drc_name string resulting in a drc_name
+string that contains garbage data after the n-th byte.
+
+Additionally it will cause us to overwrite that '\n' byte on the stack
+with NUL, potentially corrupting data on the stack.
+
+The following debugging shows an example of the drmgr utility writing
+"PHB 4543" to the add_slot sysfs attribute, but add_slot_store()
+logging a corrupted string value.
+
+ drmgr: drmgr: -c phb -a -s PHB 4543 -d 1
+ add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19
+
+Fix this by using strscpy() instead of memcpy() to ensure the string
+is NUL terminated when copied into the static drc_name buffer.
+Further, since the string is now NUL terminated the code only needs to
+change '\n' to '\0' when present.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
+[mpe: Reformat change log and add mention of possible stack corruption]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210315214821.452959-1-tyreld@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/hotplug/rpadlpar_sysfs.c | 14 ++++++--------
+ 1 file changed, 6 insertions(+), 8 deletions(-)
+
+--- a/drivers/pci/hotplug/rpadlpar_sysfs.c
++++ b/drivers/pci/hotplug/rpadlpar_sysfs.c
+@@ -39,12 +39,11 @@ static ssize_t add_slot_store(struct kob
+ if (nbytes >= MAX_DRC_NAME_LEN)
+ return 0;
+
+- memcpy(drc_name, buf, nbytes);
++ strscpy(drc_name, buf, nbytes + 1);
+
+ end = strchr(drc_name, '\n');
+- if (!end)
+- end = &drc_name[nbytes];
+- *end = '\0';
++ if (end)
++ *end = '\0';
+
+ rc = dlpar_add_slot(drc_name);
+ if (rc)
+@@ -70,12 +69,11 @@ static ssize_t remove_slot_store(struct
+ if (nbytes >= MAX_DRC_NAME_LEN)
+ return 0;
+
+- memcpy(drc_name, buf, nbytes);
++ strscpy(drc_name, buf, nbytes + 1);
+
+ end = strchr(drc_name, '\n');
+- if (!end)
+- end = &drc_name[nbytes];
+- *end = '\0';
++ if (end)
++ *end = '\0';
+
+ rc = dlpar_remove_slot(drc_name);
+ if (rc)
--- /dev/null
+From a501b048a95b79e1e34f03cac3c87ff1e9f229ad Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 18 Mar 2021 20:26:47 +0100
+Subject: x86/ioapic: Ignore IRQ2 again
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit a501b048a95b79e1e34f03cac3c87ff1e9f229ad upstream.
+
+Vitaly ran into an issue with hotplugging CPU0 on an Amazon instance where
+the matrix allocator claimed to be out of vectors. He analyzed it down to
+the point that IRQ2, the PIC cascade interrupt, which is supposed to be not
+ever routed to the IO/APIC ended up having an interrupt vector assigned
+which got moved during unplug of CPU0.
+
+The underlying issue is that IRQ2 for various reasons (see commit
+af174783b925 ("x86: I/O APIC: Never configure IRQ2" for details) is treated
+as a reserved system vector by the vector core code and is not accounted as
+a regular vector. The Amazon BIOS has an routing entry of pin2 to IRQ2
+which causes the IO/APIC setup to claim that interrupt which is granted by
+the vector domain because there is no sanity check. As a consequence the
+allocation counter of CPU0 underflows which causes a subsequent unplug to
+fail with:
+
+ [ ... ] CPU 0 has 4294967295 vectors, 589 available. Cannot disable CPU
+
+There is another sanity check missing in the matrix allocator, but the
+underlying root cause is that the IO/APIC code lost the IRQ2 ignore logic
+during the conversion to irqdomains.
+
+For almost 6 years nobody complained about this wreckage, which might
+indicate that this requirement could be lifted, but for any system which
+actually has a PIC IRQ2 is unusable by design so any routing entry has no
+effect and the interrupt cannot be connected to a device anyway.
+
+Due to that and due to history biased paranoia reasons restore the IRQ2
+ignore logic and treat it as non existent despite a routing entry claiming
+otherwise.
+
+Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces")
+Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210318192819.636943062@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/apic/io_apic.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/arch/x86/kernel/apic/io_apic.c
++++ b/arch/x86/kernel/apic/io_apic.c
+@@ -1040,6 +1040,16 @@ static int mp_map_pin_to_irq(u32 gsi, in
+ if (idx >= 0 && test_bit(mp_irqs[idx].srcbus, mp_bus_not_pci)) {
+ irq = mp_irqs[idx].srcbusirq;
+ legacy = mp_is_legacy_irq(irq);
++ /*
++ * IRQ2 is unusable for historical reasons on systems which
++ * have a legacy PIC. See the comment vs. IRQ2 further down.
++ *
++ * If this gets removed at some point then the related code
++ * in lapic_assign_system_vectors() needs to be adjusted as
++ * well.
++ */
++ if (legacy && irq == PIC_CASCADE_IR)
++ return -EINVAL;
+ }
+
+ mutex_lock(&ioapic_mutex);
projects / thirdparty / kernel / stable-queue.git / commitdiff
