4.14-stable patches

added patches:
	ftrace-do-not-blindly-read-the-ip-address-in-ftrace_bug.patch
	tracing-correct-the-length-check-which-causes-memory-corruption.patch

diff --git a/queue-4.14/ftrace-do-not-blindly-read-the-ip-address-in-ftrace_bug.patch b/queue-4.14/ftrace-do-not-blindly-read-the-ip-address-in-ftrace_bug.patch
new file mode 100644 (file)
index 0000000..d66aafe
--- /dev/null
+++ b/queue-4.14/ftrace-do-not-blindly-read-the-ip-address-in-ftrace_bug.patch
@@ -0,0 +1,55 @@
+From 6c14133d2d3f768e0a35128faac8aa6ed4815051 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Mon, 7 Jun 2021 21:39:08 -0400
+Subject: ftrace: Do not blindly read the ip address in ftrace_bug()
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 6c14133d2d3f768e0a35128faac8aa6ed4815051 upstream.
+
+It was reported that a bug on arm64 caused a bad ip address to be used for
+updating into a nop in ftrace_init(), but the error path (rightfully)
+returned -EINVAL and not -EFAULT, as the bug caused more than one error to
+occur. But because -EINVAL was returned, the ftrace_bug() tried to report
+what was at the location of the ip address, and read it directly. This
+caused the machine to panic, as the ip was not pointing to a valid memory
+address.
+
+Instead, read the ip address with copy_from_kernel_nofault() to safely
+access the memory, and if it faults, report that the address faulted,
+otherwise report what was in that location.
+
+Link: https://lore.kernel.org/lkml/20210607032329.28671-1-mark-pk.tsai@mediatek.com/
+
+Cc: stable@vger.kernel.org
+Fixes: 05736a427f7e1 ("ftrace: warn on failure to disable mcount callers")
+Reported-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
+Tested-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ftrace.c |    8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -2042,12 +2042,18 @@ static int ftrace_hash_ipmodify_update(s
+ 
+ static void print_ip_ins(const char *fmt, const unsigned char *p)
+ {
++      char ins[MCOUNT_INSN_SIZE];
+       int i;
+ 
++      if (probe_kernel_read(ins, p, MCOUNT_INSN_SIZE)) {
++              printk(KERN_CONT "%s[FAULT] %px\n", fmt, p);
++              return;
++      }
++
+       printk(KERN_CONT "%s", fmt);
+ 
+       for (i = 0; i < MCOUNT_INSN_SIZE; i++)
+-              printk(KERN_CONT "%s%02x", i ? ":" : "", p[i]);
++              printk(KERN_CONT "%s%02x", i ? ":" : "", ins[i]);
+ }
+ 
+ enum ftrace_bug_type ftrace_bug_type;

diff --git a/queue-4.14/series b/queue-4.14/series
index 4c5da865c8f197c1308348b5f06a080421217fee..ab10c39ad3c7923af0bbc120d9e544648fa1c960 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -45,3 +45,5 @@ nfsv4-nfs4_proc_set_acl-needs-to-restore-nfs_cap_uidgid_nomap-on-error.patch
 scsi-core-fix-error-handling-of-scsi_host_alloc.patch
 scsi-core-put-.shost_dev-in-failure-path-if-host-state-changes-to-running.patch
 scsi-core-only-put-parent-device-if-host-state-differs-from-shost_created.patch
+ftrace-do-not-blindly-read-the-ip-address-in-ftrace_bug.patch
+tracing-correct-the-length-check-which-causes-memory-corruption.patch

diff --git a/queue-4.14/tracing-correct-the-length-check-which-causes-memory-corruption.patch b/queue-4.14/tracing-correct-the-length-check-which-causes-memory-corruption.patch
new file mode 100644 (file)
index 0000000..47a56db
--- /dev/null
+++ b/queue-4.14/tracing-correct-the-length-check-which-causes-memory-corruption.patch
@@ -0,0 +1,102 @@
+From 3e08a9f9760f4a70d633c328a76408e62d6f80a3 Mon Sep 17 00:00:00 2001
+From: Liangyan <liangyan.peng@linux.alibaba.com>
+Date: Mon, 7 Jun 2021 20:57:34 +0800
+Subject: tracing: Correct the length check which causes memory corruption
+
+From: Liangyan <liangyan.peng@linux.alibaba.com>
+
+commit 3e08a9f9760f4a70d633c328a76408e62d6f80a3 upstream.
+
+We've suffered from severe kernel crashes due to memory corruption on
+our production environment, like,
+
+Call Trace:
+[1640542.554277] general protection fault: 0000 [#1] SMP PTI
+[1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G
+[1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190
+[1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286
+[1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:
+0000000006e931bf
+[1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:
+ffff9a45ff004300
+[1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:
+0000000000000000
+[1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:
+ffffffff9a20608d
+[1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:
+696c662f65636976
+[1640542.563128] FS:  00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)
+knlGS:0000000000000000
+[1640542.563937] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:
+00000000003606e0
+[1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
+0000000000000000
+[1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
+0000000000000400
+[1640542.566742] Call Trace:
+[1640542.567009]  anon_vma_clone+0x5d/0x170
+[1640542.567417]  __split_vma+0x91/0x1a0
+[1640542.567777]  do_munmap+0x2c6/0x320
+[1640542.568128]  vm_munmap+0x54/0x70
+[1640542.569990]  __x64_sys_munmap+0x22/0x30
+[1640542.572005]  do_syscall_64+0x5b/0x1b0
+[1640542.573724]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
+[1640542.575642] RIP: 0033:0x7f45d6e61e27
+
+James Wang has reproduced it stably on the latest 4.19 LTS.
+After some debugging, we finally proved that it's due to ftrace
+buffer out-of-bound access using a debug tool as follows:
+[   86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000
+[   86.780806]  no_context+0xdf/0x3c0
+[   86.784327]  __do_page_fault+0x252/0x470
+[   86.788367]  do_page_fault+0x32/0x140
+[   86.792145]  page_fault+0x1e/0x30
+[   86.795576]  strncpy_from_unsafe+0x66/0xb0
+[   86.799789]  fetch_memory_string+0x25/0x40
+[   86.804002]  fetch_deref_string+0x51/0x60
+[   86.808134]  kprobe_trace_func+0x32d/0x3a0
+[   86.812347]  kprobe_dispatcher+0x45/0x50
+[   86.816385]  kprobe_ftrace_handler+0x90/0xf0
+[   86.820779]  ftrace_ops_assist_func+0xa1/0x140
+[   86.825340]  0xffffffffc00750bf
+[   86.828603]  do_sys_open+0x5/0x1f0
+[   86.832124]  do_syscall_64+0x5b/0x1b0
+[   86.835900]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+commit b220c049d519 ("tracing: Check length before giving out
+the filter buffer") adds length check to protect trace data
+overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent
+overflow entirely, the length check should also take the sizeof
+entry->array[0] into account, since this array[0] is filled the
+length of trace data and occupy addtional space and risk overflow.
+
+Link: https://lkml.kernel.org/r/20210607125734.1770447-1-liangyan.peng@linux.alibaba.com
+
+Cc: stable@vger.kernel.org
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Xunlei Pang <xlpang@linux.alibaba.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Fixes: b220c049d519 ("tracing: Check length before giving out the filter buffer")
+Reviewed-by: Xunlei Pang <xlpang@linux.alibaba.com>
+Reviewed-by: yinbinbin <yinbinbin@alibabacloud.com>
+Reviewed-by: Wetp Zhang <wetp.zy@linux.alibaba.com>
+Tested-by: James Wang <jnwang@linux.alibaba.com>
+Signed-off-by: Liangyan <liangyan.peng@linux.alibaba.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -2274,7 +2274,7 @@ trace_event_buffer_lock_reserve(struct r
+           (entry = this_cpu_read(trace_buffered_event))) {
+               /* Try to use the per cpu buffer first */
+               val = this_cpu_inc_return(trace_buffered_event_cnt);
+-              if ((len < (PAGE_SIZE - sizeof(*entry))) && val == 1) {
++              if ((len < (PAGE_SIZE - sizeof(*entry) - sizeof(entry->array[0]))) && val == 1) {
+                       trace_event_setup(entry, type, flags, pc);
+                       entry->array[0] = len;
+                       return entry;