From: Greg Kroah-Hartman Date: Wed, 27 Oct 2021 16:11:20 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.4.291~49 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=acf0e65742577977134f0d2f13267fd023afe545;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: arm-9132-1-fix-__get_user_check-failure-with-arm-kasan-images.patch arm-9133-1-mm-proc-macros-ensure-_tlb_fns-are-4b-aligned.patch arm-9134-1-remove-duplicate-memcpy-definition.patch arm-9138-1-fix-link-warning-with-xip-frame-pointer.patch arm-9139-1-kprobes-fix-arch_init_kprobes-prototype.patch arm-9141-1-only-warn-about-xip-address-when-not-compile-testing.patch io_uring-don-t-take-uring_lock-during-iowq-cancel.patch --- diff --git a/queue-5.10/arm-9132-1-fix-__get_user_check-failure-with-arm-kasan-images.patch b/queue-5.10/arm-9132-1-fix-__get_user_check-failure-with-arm-kasan-images.patch new file mode 100644 index 00000000000..f2ab134b0ca --- /dev/null +++ b/queue-5.10/arm-9132-1-fix-__get_user_check-failure-with-arm-kasan-images.patch @@ -0,0 +1,96 @@ +From df909df0770779f1a5560c2bb641a2809655ef28 Mon Sep 17 00:00:00 2001 +From: Lexi Shao +Date: Thu, 23 Sep 2021 03:41:25 +0100 +Subject: ARM: 9132/1: Fix __get_user_check failure with ARM KASAN images + +From: Lexi Shao + +commit df909df0770779f1a5560c2bb641a2809655ef28 upstream. + +ARM: kasan: Fix __get_user_check failure with kasan + +In macro __get_user_check defined in arch/arm/include/asm/uaccess.h, +error code is store in register int __e(r0). When kasan is +enabled, assigning value to kernel address might trigger kasan check, +which unexpectedly overwrites r0 and causes undefined behavior on arm +kasan images. + +One example is failure in do_futex and results in process soft lockup. +Log: +watchdog: BUG: soft lockup - CPU#0 stuck for 62946ms! [rs:main +Q:Reg:1151] +... +(__asan_store4) from (futex_wait_setup+0xf8/0x2b4) +(futex_wait_setup) from (futex_wait+0x138/0x394) +(futex_wait) from (do_futex+0x164/0xe40) +(do_futex) from (sys_futex_time32+0x178/0x230) +(sys_futex_time32) from (ret_fast_syscall+0x0/0x50) + +The soft lockup happens in function futex_wait_setup. The reason is +function get_futex_value_locked always return EINVAL, thus pc jump +back to retry label and causes looping. + +This line in function get_futex_value_locked + ret = __get_user(*dest, from); +is expanded to + *dest = (typeof(*(p))) __r2; , +in macro __get_user_check. Writing to pointer dest triggers kasan check +and overwrites the return value of __get_user_x function. +The assembly code of get_futex_value_locked in kernel/futex.c: +... +c01f6dc8: eb0b020e bl c04b7608 <__get_user_4> +// "x = (typeof(*(p))) __r2;" triggers kasan check and r0 is overwritten +c01f6dCc: e1a00007 mov r0, r7 +c01f6dd0: e1a05002 mov r5, r2 +c01f6dd4: eb04f1e6 bl c0333574 <__asan_store4> +c01f6dd8: e5875000 str r5, [r7] +// save ret value of __get_user(*dest, from), which is dest address now +c01f6ddc: e1a05000 mov r5, r0 +... +// checking return value of __get_user failed +c01f6e00: e3550000 cmp r5, #0 +... +c01f6e0c: 01a00005 moveq r0, r5 +// assign return value to EINVAL +c01f6e10: 13e0000d mvnne r0, #13 + +Return value is the destination address of get_user thus certainly +non-zero, so get_futex_value_locked always return EINVAL. + +Fix it by using a tmp vairable to store the error code before the +assignment. This fix has no effects to non-kasan images thanks to compiler +optimization. It only affects cases that overwrite r0 due to kasan check. + +This should fix bug discussed in Link: +[1] https://lore.kernel.org/linux-arm-kernel/0ef7c2a5-5d8b-c5e0-63fa-31693fd4495c@gmail.com/ + +Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") +Signed-off-by: Lexi Shao +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/include/asm/uaccess.h | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/arm/include/asm/uaccess.h ++++ b/arch/arm/include/asm/uaccess.h +@@ -200,6 +200,7 @@ extern int __get_user_64t_4(void *); + register unsigned long __l asm("r1") = __limit; \ + register int __e asm("r0"); \ + unsigned int __ua_flags = uaccess_save_and_enable(); \ ++ int __tmp_e; \ + switch (sizeof(*(__p))) { \ + case 1: \ + if (sizeof((x)) >= 8) \ +@@ -227,9 +228,10 @@ extern int __get_user_64t_4(void *); + break; \ + default: __e = __get_user_bad(); break; \ + } \ ++ __tmp_e = __e; \ + uaccess_restore(__ua_flags); \ + x = (typeof(*(p))) __r2; \ +- __e; \ ++ __tmp_e; \ + }) + + #define get_user(x, p) \ diff --git a/queue-5.10/arm-9133-1-mm-proc-macros-ensure-_tlb_fns-are-4b-aligned.patch b/queue-5.10/arm-9133-1-mm-proc-macros-ensure-_tlb_fns-are-4b-aligned.patch new file mode 100644 index 00000000000..236bae3ef75 --- /dev/null +++ b/queue-5.10/arm-9133-1-mm-proc-macros-ensure-_tlb_fns-are-4b-aligned.patch @@ -0,0 +1,41 @@ +From e6a0c958bdf9b2e1b57501fc9433a461f0a6aadd Mon Sep 17 00:00:00 2001 +From: Nick Desaulniers +Date: Mon, 4 Oct 2021 18:03:28 +0100 +Subject: ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned + +From: Nick Desaulniers + +commit e6a0c958bdf9b2e1b57501fc9433a461f0a6aadd upstream. + +A kernel built with CONFIG_THUMB2_KERNEL=y and using clang as the +assembler could generate non-naturally-aligned v7wbi_tlb_fns which +results in a boot failure. The original commit adding the macro missed +the .align directive on this data. + +Link: https://github.com/ClangBuiltLinux/linux/issues/1447 +Link: https://lore.kernel.org/all/0699da7b-354f-aecc-a62f-e25693209af4@linaro.org/ +Debugged-by: Ard Biesheuvel +Debugged-by: Nathan Chancellor +Debugged-by: Richard Henderson + +Fixes: 66a625a88174 ("ARM: mm: proc-macros: Add generic proc/cache/tlb struct definition macros") +Suggested-by: Ard Biesheuvel +Acked-by: Ard Biesheuvel +Signed-off-by: Nick Desaulniers +Tested-by: Nathan Chancellor +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/mm/proc-macros.S | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm/mm/proc-macros.S ++++ b/arch/arm/mm/proc-macros.S +@@ -340,6 +340,7 @@ ENTRY(\name\()_cache_fns) + + .macro define_tlb_functions name:req, flags_up:req, flags_smp + .type \name\()_tlb_fns, #object ++ .align 2 + ENTRY(\name\()_tlb_fns) + .long \name\()_flush_user_tlb_range + .long \name\()_flush_kern_tlb_range diff --git a/queue-5.10/arm-9134-1-remove-duplicate-memcpy-definition.patch b/queue-5.10/arm-9134-1-remove-duplicate-memcpy-definition.patch new file mode 100644 index 00000000000..59a1e19a814 --- /dev/null +++ b/queue-5.10/arm-9134-1-remove-duplicate-memcpy-definition.patch @@ -0,0 +1,56 @@ +From eaf6cc7165c9c5aa3c2f9faa03a98598123d0afb Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Mon, 18 Oct 2021 15:30:04 +0100 +Subject: ARM: 9134/1: remove duplicate memcpy() definition + +From: Arnd Bergmann + +commit eaf6cc7165c9c5aa3c2f9faa03a98598123d0afb upstream. + +Both the decompressor code and the kasan logic try to override +the memcpy() and memmove() definitions, which leading to a clash +in a KASAN-enabled kernel with XZ decompression: + +arch/arm/boot/compressed/decompress.c:50:9: error: 'memmove' macro redefined [-Werror,-Wmacro-redefined] + #define memmove memmove + ^ +arch/arm/include/asm/string.h:59:9: note: previous definition is here + #define memmove(dst, src, len) __memmove(dst, src, len) + ^ +arch/arm/boot/compressed/decompress.c:51:9: error: 'memcpy' macro redefined [-Werror,-Wmacro-redefined] + #define memcpy memcpy + ^ +arch/arm/include/asm/string.h:58:9: note: previous definition is here + #define memcpy(dst, src, len) __memcpy(dst, src, len) + ^ + +Here we want the set of functions from the decompressor, so undefine +the other macros before the override. + +Link: https://lore.kernel.org/linux-arm-kernel/CACRpkdZYJogU_SN3H9oeVq=zJkRgRT1gDz3xp59gdqWXxw-B=w@mail.gmail.com/ +Link: https://lore.kernel.org/lkml/202105091112.F5rmd4By-lkp@intel.com/ + +Fixes: d6d51a96c7d6 ("ARM: 9014/2: Replace string mem* functions for KASan") +Fixes: a7f464f3db93 ("ARM: 7001/2: Wire up support for the XZ decompressor") +Reported-by: kernel test robot +Reviewed-by: Linus Walleij +Signed-off-by: Arnd Bergmann +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/compressed/decompress.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/arm/boot/compressed/decompress.c ++++ b/arch/arm/boot/compressed/decompress.c +@@ -47,7 +47,10 @@ extern char * strchrnul(const char *, in + #endif + + #ifdef CONFIG_KERNEL_XZ ++/* Prevent KASAN override of string helpers in decompressor */ ++#undef memmove + #define memmove memmove ++#undef memcpy + #define memcpy memcpy + #include "../../../../lib/decompress_unxz.c" + #endif diff --git a/queue-5.10/arm-9138-1-fix-link-warning-with-xip-frame-pointer.patch b/queue-5.10/arm-9138-1-fix-link-warning-with-xip-frame-pointer.patch new file mode 100644 index 00000000000..24b17aed288 --- /dev/null +++ b/queue-5.10/arm-9138-1-fix-link-warning-with-xip-frame-pointer.patch @@ -0,0 +1,43 @@ +From 44cc6412e66b2b84544eaf2e14cf1764301e2a80 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Mon, 18 Oct 2021 15:30:08 +0100 +Subject: ARM: 9138/1: fix link warning with XIP + frame-pointer + +From: Arnd Bergmann + +commit 44cc6412e66b2b84544eaf2e14cf1764301e2a80 upstream. + +When frame pointers are used instead of the ARM unwinder, +and the kernel is built using clang with an external assembler +and CONFIG_XIP_KERNEL, every file produces two warnings +like: + +arm-linux-gnueabi-ld: warning: orphan section `.ARM.extab' from `net/mac802154/util.o' being placed in section `.ARM.extab' +arm-linux-gnueabi-ld: warning: orphan section `.ARM.exidx' from `net/mac802154/util.o' being placed in section `.ARM.exidx' + +The same fix was already merged for the normal (non-XIP) + +linker script, with a longer description. + +Fixes: c39866f268f8 ("arm/build: Always handle .ARM.exidx and .ARM.extab sections") +Reviewed-by: Kees Cook +Signed-off-by: Arnd Bergmann +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/kernel/vmlinux-xip.lds.S | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/arm/kernel/vmlinux-xip.lds.S ++++ b/arch/arm/kernel/vmlinux-xip.lds.S +@@ -40,6 +40,10 @@ SECTIONS + ARM_DISCARD + *(.alt.smp.init) + *(.pv_table) ++#ifndef CONFIG_ARM_UNWIND ++ *(.ARM.exidx) *(.ARM.exidx.*) ++ *(.ARM.extab) *(.ARM.extab.*) ++#endif + } + + . = XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR); diff --git a/queue-5.10/arm-9139-1-kprobes-fix-arch_init_kprobes-prototype.patch b/queue-5.10/arm-9139-1-kprobes-fix-arch_init_kprobes-prototype.patch new file mode 100644 index 00000000000..1a69c79e657 --- /dev/null +++ b/queue-5.10/arm-9139-1-kprobes-fix-arch_init_kprobes-prototype.patch @@ -0,0 +1,38 @@ +From 1f323127cab086e4fd618981b1e5edc396eaf0f4 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Mon, 18 Oct 2021 15:30:09 +0100 +Subject: ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype + +From: Arnd Bergmann + +commit 1f323127cab086e4fd618981b1e5edc396eaf0f4 upstream. + +With extra warnings enabled, gcc complains about this function +definition: + +arch/arm/probes/kprobes/core.c: In function 'arch_init_kprobes': +arch/arm/probes/kprobes/core.c:465:12: warning: old-style function definition [-Wold-style-definition] + 465 | int __init arch_init_kprobes() + +Link: https://lore.kernel.org/all/20201027093057.c685a14b386acacb3c449e3d@kernel.org/ + +Fixes: 24ba613c9d6c ("ARM kprobes: core code") +Acked-by: Masami Hiramatsu +Signed-off-by: Arnd Bergmann +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/probes/kprobes/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/probes/kprobes/core.c ++++ b/arch/arm/probes/kprobes/core.c +@@ -462,7 +462,7 @@ static struct undef_hook kprobes_arm_bre + + #endif /* !CONFIG_THUMB2_KERNEL */ + +-int __init arch_init_kprobes() ++int __init arch_init_kprobes(void) + { + arm_probes_decode_init(); + #ifdef CONFIG_THUMB2_KERNEL diff --git a/queue-5.10/arm-9141-1-only-warn-about-xip-address-when-not-compile-testing.patch b/queue-5.10/arm-9141-1-only-warn-about-xip-address-when-not-compile-testing.patch new file mode 100644 index 00000000000..243bd991fec --- /dev/null +++ b/queue-5.10/arm-9141-1-only-warn-about-xip-address-when-not-compile-testing.patch @@ -0,0 +1,37 @@ +From 48ccc8edf5b90622cdc4f8878e0042ab5883e2ca Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Mon, 18 Oct 2021 15:30:37 +0100 +Subject: ARM: 9141/1: only warn about XIP address when not compile testing + +From: Arnd Bergmann + +commit 48ccc8edf5b90622cdc4f8878e0042ab5883e2ca upstream. + +In randconfig builds, we sometimes come across this warning: + +arm-linux-gnueabi-ld: XIP start address may cause MPU programming issues + +While this is helpful for actual systems to figure out why it +fails, the warning does not provide any benefit for build testing, +so guard it in a check for CONFIG_COMPILE_TEST, which is usually +set on randconfig builds. + +Fixes: 216218308cfb ("ARM: 8713/1: NOMMU: Support MPU in XIP configuration") +Signed-off-by: Arnd Bergmann +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/kernel/vmlinux-xip.lds.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/kernel/vmlinux-xip.lds.S ++++ b/arch/arm/kernel/vmlinux-xip.lds.S +@@ -176,7 +176,7 @@ ASSERT((__arch_info_end - __arch_info_be + ASSERT((_end - __bss_start) >= 12288, ".bss too small for CONFIG_XIP_DEFLATED_DATA") + #endif + +-#ifdef CONFIG_ARM_MPU ++#if defined(CONFIG_ARM_MPU) && !defined(CONFIG_COMPILE_TEST) + /* + * Due to PMSAv7 restriction on base address and size we have to + * enforce minimal alignment restrictions. It was seen that weaker diff --git a/queue-5.10/io_uring-don-t-take-uring_lock-during-iowq-cancel.patch b/queue-5.10/io_uring-don-t-take-uring_lock-during-iowq-cancel.patch new file mode 100644 index 00000000000..7c7f051f258 --- /dev/null +++ b/queue-5.10/io_uring-don-t-take-uring_lock-during-iowq-cancel.patch @@ -0,0 +1,83 @@ +From 792bb6eb862333658bf1bd2260133f0507e2da8d Mon Sep 17 00:00:00 2001 +From: Pavel Begunkov +Date: Thu, 18 Feb 2021 22:32:51 +0000 +Subject: io_uring: don't take uring_lock during iowq cancel + +From: Pavel Begunkov + +commit 792bb6eb862333658bf1bd2260133f0507e2da8d upstream. + +[ 97.866748] a.out/2890 is trying to acquire lock: +[ 97.867829] ffff8881046763e8 (&ctx->uring_lock){+.+.}-{3:3}, at: +io_wq_submit_work+0x155/0x240 +[ 97.869735] +[ 97.869735] but task is already holding lock: +[ 97.871033] ffff88810dfe0be8 (&ctx->uring_lock){+.+.}-{3:3}, at: +__x64_sys_io_uring_enter+0x3f0/0x5b0 +[ 97.873074] +[ 97.873074] other info that might help us debug this: +[ 97.874520] Possible unsafe locking scenario: +[ 97.874520] +[ 97.875845] CPU0 +[ 97.876440] ---- +[ 97.877048] lock(&ctx->uring_lock); +[ 97.877961] lock(&ctx->uring_lock); +[ 97.878881] +[ 97.878881] *** DEADLOCK *** +[ 97.878881] +[ 97.880341] May be due to missing lock nesting notation +[ 97.880341] +[ 97.881952] 1 lock held by a.out/2890: +[ 97.882873] #0: ffff88810dfe0be8 (&ctx->uring_lock){+.+.}-{3:3}, at: +__x64_sys_io_uring_enter+0x3f0/0x5b0 +[ 97.885108] +[ 97.885108] stack backtrace: +[ 97.890457] Call Trace: +[ 97.891121] dump_stack+0xac/0xe3 +[ 97.891972] __lock_acquire+0xab6/0x13a0 +[ 97.892940] lock_acquire+0x2c3/0x390 +[ 97.894894] __mutex_lock+0xae/0x9f0 +[ 97.901101] io_wq_submit_work+0x155/0x240 +[ 97.902112] io_wq_cancel_cb+0x162/0x490 +[ 97.904126] io_async_find_and_cancel+0x3b/0x140 +[ 97.905247] io_issue_sqe+0x86d/0x13e0 +[ 97.909122] __io_queue_sqe+0x10b/0x550 +[ 97.913971] io_queue_sqe+0x235/0x470 +[ 97.914894] io_submit_sqes+0xcce/0xf10 +[ 97.917872] __x64_sys_io_uring_enter+0x3fb/0x5b0 +[ 97.921424] do_syscall_64+0x2d/0x40 +[ 97.922329] entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +While holding uring_lock, e.g. from inline execution, async cancel +request may attempt cancellations through io_wq_submit_work, which may +try to grab a lock. Delay it to task_work, so we do it from a clean +context and don't have to worry about locking. + +Cc: # 5.5+ +Fixes: c07e6719511e ("io_uring: hold uring_lock while completing failed polled io in io_wq_submit_work()") +Reported-by: Abaci +Reported-by: Hao Xu +Signed-off-by: Pavel Begunkov +Signed-off-by: Jens Axboe +[Lee: The first hunk solves a different (double free) issue in v5.10. + Only the first hunk of the original patch is relevant to v5.10 AND + the first hunk of the original patch is only relevant to v5.10] +Reported-by: syzbot+59d8a1f4e60c20c066cf@syzkaller.appspotmail.com +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + fs/io_uring.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/io_uring.c ++++ b/fs/io_uring.c +@@ -2075,7 +2075,9 @@ static void io_req_task_cancel(struct ca + struct io_kiocb *req = container_of(cb, struct io_kiocb, task_work); + struct io_ring_ctx *ctx = req->ctx; + ++ mutex_lock(&ctx->uring_lock); + __io_req_task_cancel(req, -ECANCELED); ++ mutex_unlock(&ctx->uring_lock); + percpu_ref_put(&ctx->refs); + } + diff --git a/queue-5.10/series b/queue-5.10/series index f4c28d0b619..0b42d7b8f5b 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -4,3 +4,4 @@ arm-9134-1-remove-duplicate-memcpy-definition.patch arm-9138-1-fix-link-warning-with-xip-frame-pointer.patch arm-9139-1-kprobes-fix-arch_init_kprobes-prototype.patch arm-9141-1-only-warn-about-xip-address-when-not-compile-testing.patch +io_uring-don-t-take-uring_lock-during-iowq-cancel.patch