From: Greg Kroah-Hartman Date: Mon, 22 Mar 2021 09:26:37 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v4.4.263~34 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1c7aaa83730333e333055a97f0447fea9798b63d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: pci-rpadlpar-fix-potential-drc_name-corruption-in-store-functions.patch x86-ioapic-ignore-irq2-again.patch --- diff --git a/queue-4.4/pci-rpadlpar-fix-potential-drc_name-corruption-in-store-functions.patch b/queue-4.4/pci-rpadlpar-fix-potential-drc_name-corruption-in-store-functions.patch new file mode 100644 index 00000000000..9f68a5cc467 --- /dev/null +++ b/queue-4.4/pci-rpadlpar-fix-potential-drc_name-corruption-in-store-functions.patch @@ -0,0 +1,83 @@ +From cc7a0bb058b85ea03db87169c60c7cfdd5d34678 Mon Sep 17 00:00:00 2001 +From: Tyrel Datwyler +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 + +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 +[mpe: Reformat change log and add mention of possible stack corruption] +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20210315214821.452959-1-tyreld@linux.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-4.4/series b/queue-4.4/series index b619e36d542..c6c93456e1b 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -7,3 +7,5 @@ nfsd-repair-misuse-of-sv_lock-in-5.10.16-rt30.patch scsi-lpfc-fix-some-error-codes-in-debugfs.patch usb-replace-hardcode-maximum-usb-string-length-by-definition.patch usb-gadget-configfs-fix-kasan-use-after-free.patch +pci-rpadlpar-fix-potential-drc_name-corruption-in-store-functions.patch +x86-ioapic-ignore-irq2-again.patch diff --git a/queue-4.4/x86-ioapic-ignore-irq2-again.patch b/queue-4.4/x86-ioapic-ignore-irq2-again.patch new file mode 100644 index 00000000000..87074d2e6a4 --- /dev/null +++ b/queue-4.4/x86-ioapic-ignore-irq2-again.patch @@ -0,0 +1,69 @@ +From a501b048a95b79e1e34f03cac3c87ff1e9f229ad Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 18 Mar 2021 20:26:47 +0100 +Subject: x86/ioapic: Ignore IRQ2 again + +From: Thomas Gleixner + +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 +Signed-off-by: Thomas Gleixner +Tested-by: Vitaly Kuznetsov +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210318192819.636943062@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + 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);