From: Greg Kroah-Hartman Date: Wed, 9 Dec 2020 08:46:16 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v5.9.14~47 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=553c1d828dcc2c93fb9c20bc0631e3ce27db6f80;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: cifs-fix-potential-use-after-free-in-cifs_echo_request.patch ftrace-fix-updating-ftrace_fl_tramp.patch powerpc-pseries-pass-msi-affinity-to-irq_create_mapping.patch --- diff --git a/queue-4.14/cifs-fix-potential-use-after-free-in-cifs_echo_request.patch b/queue-4.14/cifs-fix-potential-use-after-free-in-cifs_echo_request.patch new file mode 100644 index 00000000000..4539f67a969 --- /dev/null +++ b/queue-4.14/cifs-fix-potential-use-after-free-in-cifs_echo_request.patch @@ -0,0 +1,51 @@ +From 212253367dc7b49ed3fc194ce71b0992eacaecf2 Mon Sep 17 00:00:00 2001 +From: Paulo Alcantara +Date: Sat, 28 Nov 2020 16:54:02 -0300 +Subject: cifs: fix potential use-after-free in cifs_echo_request() + +From: Paulo Alcantara + +commit 212253367dc7b49ed3fc194ce71b0992eacaecf2 upstream. + +This patch fixes a potential use-after-free bug in +cifs_echo_request(). + +For instance, + + thread 1 + -------- + cifs_demultiplex_thread() + clean_demultiplex_info() + kfree(server) + + thread 2 (workqueue) + -------- + apic_timer_interrupt() + smp_apic_timer_interrupt() + irq_exit() + __do_softirq() + run_timer_softirq() + call_timer_fn() + cifs_echo_request() <- use-after-free in server ptr + +Signed-off-by: Paulo Alcantara (SUSE) +CC: Stable +Reviewed-by: Ronnie Sahlberg +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -756,6 +756,8 @@ static void clean_demultiplex_info(struc + list_del_init(&server->tcp_ses_list); + spin_unlock(&cifs_tcp_ses_lock); + ++ cancel_delayed_work_sync(&server->echo); ++ + spin_lock(&GlobalMid_Lock); + server->tcpStatus = CifsExiting; + spin_unlock(&GlobalMid_Lock); diff --git a/queue-4.14/ftrace-fix-updating-ftrace_fl_tramp.patch b/queue-4.14/ftrace-fix-updating-ftrace_fl_tramp.patch new file mode 100644 index 00000000000..8bd820366d5 --- /dev/null +++ b/queue-4.14/ftrace-fix-updating-ftrace_fl_tramp.patch @@ -0,0 +1,86 @@ +From 4c75b0ff4e4bf7a45b5aef9639799719c28d0073 Mon Sep 17 00:00:00 2001 +From: "Naveen N. Rao" +Date: Thu, 26 Nov 2020 23:38:38 +0530 +Subject: ftrace: Fix updating FTRACE_FL_TRAMP + +From: Naveen N. Rao + +commit 4c75b0ff4e4bf7a45b5aef9639799719c28d0073 upstream. + +On powerpc, kprobe-direct.tc triggered FTRACE_WARN_ON() in +ftrace_get_addr_new() followed by the below message: + Bad trampoline accounting at: 000000004222522f (wake_up_process+0xc/0x20) (f0000001) + +The set of steps leading to this involved: +- modprobe ftrace-direct-too +- enable_probe +- modprobe ftrace-direct +- rmmod ftrace-direct <-- trigger + +The problem turned out to be that we were not updating flags in the +ftrace record properly. From the above message about the trampoline +accounting being bad, it can be seen that the ftrace record still has +FTRACE_FL_TRAMP set though ftrace-direct module is going away. This +happens because we are checking if any ftrace_ops has the +FTRACE_FL_TRAMP flag set _before_ updating the filter hash. + +The fix for this is to look for any _other_ ftrace_ops that also needs +FTRACE_FL_TRAMP. + +Link: https://lkml.kernel.org/r/56c113aa9c3e10c19144a36d9684c7882bf09af5.1606412433.git.naveen.n.rao@linux.vnet.ibm.com + +Cc: stable@vger.kernel.org +Fixes: a124692b698b0 ("ftrace: Enable trampoline when rec count returns back to one") +Signed-off-by: Naveen N. Rao +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/ftrace.c | 22 +++++++++++++++++++++- + 1 file changed, 21 insertions(+), 1 deletion(-) + +--- a/kernel/trace/ftrace.c ++++ b/kernel/trace/ftrace.c +@@ -1715,6 +1715,8 @@ static bool test_rec_ops_needs_regs(stru + static struct ftrace_ops * + ftrace_find_tramp_ops_any(struct dyn_ftrace *rec); + static struct ftrace_ops * ++ftrace_find_tramp_ops_any_other(struct dyn_ftrace *rec, struct ftrace_ops *op_exclude); ++static struct ftrace_ops * + ftrace_find_tramp_ops_next(struct dyn_ftrace *rec, struct ftrace_ops *ops); + + static bool __ftrace_hash_rec_update(struct ftrace_ops *ops, +@@ -1852,7 +1854,7 @@ static bool __ftrace_hash_rec_update(str + * to it. + */ + if (ftrace_rec_count(rec) == 1 && +- ftrace_find_tramp_ops_any(rec)) ++ ftrace_find_tramp_ops_any_other(rec, ops)) + rec->flags |= FTRACE_FL_TRAMP; + else + rec->flags &= ~FTRACE_FL_TRAMP; +@@ -2274,6 +2276,24 @@ ftrace_find_tramp_ops_any(struct dyn_ftr + continue; + + if (hash_contains_ip(ip, op->func_hash)) ++ return op; ++ } while_for_each_ftrace_op(op); ++ ++ return NULL; ++} ++ ++static struct ftrace_ops * ++ftrace_find_tramp_ops_any_other(struct dyn_ftrace *rec, struct ftrace_ops *op_exclude) ++{ ++ struct ftrace_ops *op; ++ unsigned long ip = rec->ip; ++ ++ do_for_each_ftrace_op(op, ftrace_ops_list) { ++ ++ if (op == op_exclude || !op->trampoline) ++ continue; ++ ++ if (hash_contains_ip(ip, op->func_hash)) + return op; + } while_for_each_ftrace_op(op); + diff --git a/queue-4.14/powerpc-pseries-pass-msi-affinity-to-irq_create_mapping.patch b/queue-4.14/powerpc-pseries-pass-msi-affinity-to-irq_create_mapping.patch new file mode 100644 index 00000000000..49f2d4d9395 --- /dev/null +++ b/queue-4.14/powerpc-pseries-pass-msi-affinity-to-irq_create_mapping.patch @@ -0,0 +1,54 @@ +From 9ea69a55b3b9a71cded9726af591949c1138f235 Mon Sep 17 00:00:00 2001 +From: Laurent Vivier +Date: Thu, 26 Nov 2020 09:28:52 +0100 +Subject: powerpc/pseries: Pass MSI affinity to irq_create_mapping() + +From: Laurent Vivier + +commit 9ea69a55b3b9a71cded9726af591949c1138f235 upstream. + +With virtio multiqueue, normally each queue IRQ is mapped to a CPU. + +Commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity") exposed +an existing shortcoming of the arch code by moving virtio_scsi to +the automatic IRQ affinity assignment. + +The affinity is correctly computed in msi_desc but this is not applied +to the system IRQs. + +It appears the affinity is correctly passed to rtas_setup_msi_irqs() but +lost at this point and never passed to irq_domain_alloc_descs() +(see commit 06ee6d571f0e ("genirq: Add affinity hint to irq allocation")) +because irq_create_mapping() doesn't take an affinity parameter. + +Use the new irq_create_mapping_affinity() function, which allows to forward +the affinity setting from rtas_setup_msi_irqs() to irq_domain_alloc_descs(). + +With this change, the virtqueues are correctly dispatched between the CPUs +on pseries. + +Fixes: e75eafb9b039 ("genirq/msi: Switch to new irq spreading infrastructure") +Signed-off-by: Laurent Vivier +Signed-off-by: Thomas Gleixner +Reviewed-by: Greg Kurz +Acked-by: Michael Ellerman +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20201126082852.1178497-3-lvivier@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/platforms/pseries/msi.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/platforms/pseries/msi.c ++++ b/arch/powerpc/platforms/pseries/msi.c +@@ -462,7 +462,8 @@ again: + return hwirq; + } + +- virq = irq_create_mapping(NULL, hwirq); ++ virq = irq_create_mapping_affinity(NULL, hwirq, ++ entry->affinity); + + if (!virq) { + pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq); diff --git a/queue-4.14/series b/queue-4.14/series index 9e3d2026416..6d59c8f969b 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -13,3 +13,6 @@ tty-fix-pgrp-locking-in-tiocspgrp.patch tty-fix-session-locking.patch alsa-hda-realtek-add-new-codec-supported-for-alc897.patch alsa-hda-generic-add-option-to-enforce-preferred_dacs-pairs.patch +ftrace-fix-updating-ftrace_fl_tramp.patch +cifs-fix-potential-use-after-free-in-cifs_echo_request.patch +powerpc-pseries-pass-msi-affinity-to-irq_create_mapping.patch