From: Greg Kroah-Hartman Date: Mon, 14 Jun 2021 08:52:52 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v4.4.273~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4e2124f29d0d75b04787351bdc26fb8fdad889dd;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-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-5.4/ftrace-do-not-blindly-read-the-ip-address-in-ftrace_bug.patch b/queue-5.4/ftrace-do-not-blindly-read-the-ip-address-in-ftrace_bug.patch new file mode 100644 index 00000000000..eaa97a2c5aa --- /dev/null +++ b/queue-5.4/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)" +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) + +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 +Tested-by: Mark-PK Tsai +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/ftrace.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/kernel/trace/ftrace.c ++++ b/kernel/trace/ftrace.c +@@ -1953,12 +1953,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-5.4/series b/queue-5.4/series index 8a706b0b7cb..dd3a9bf76dc 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -80,3 +80,5 @@ scsi-core-fix-error-handling-of-scsi_host_alloc.patch scsi-core-fix-failure-handling-of-scsi_add_host_with_dma.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-5.4/tracing-correct-the-length-check-which-causes-memory-corruption.patch b/queue-5.4/tracing-correct-the-length-check-which-causes-memory-corruption.patch new file mode 100644 index 00000000000..468a2237feb --- /dev/null +++ b/queue-5.4/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 +Date: Mon, 7 Jun 2021 20:57:34 +0800 +Subject: tracing: Correct the length check which causes memory corruption + +From: Liangyan + +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 +Cc: Xunlei Pang +Cc: Greg Kroah-Hartman +Fixes: b220c049d519 ("tracing: Check length before giving out the filter buffer") +Reviewed-by: Xunlei Pang +Reviewed-by: yinbinbin +Reviewed-by: Wetp Zhang +Tested-by: James Wang +Signed-off-by: Liangyan +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -2487,7 +2487,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;