--- /dev/null
+From df909df0770779f1a5560c2bb641a2809655ef28 Mon Sep 17 00:00:00 2001
+From: Lexi Shao <shaolexi@huawei.com>
+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 <shaolexi@huawei.com>
+
+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 <shaolexi@huawei.com>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) \
--- /dev/null
+From e6a0c958bdf9b2e1b57501fc9433a461f0a6aadd Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <ndesaulniers@google.com>
+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 <ndesaulniers@google.com>
+
+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 <ardb@kernel.org>
+Debugged-by: Nathan Chancellor <nathan@kernel.org>
+Debugged-by: Richard Henderson <richard.henderson@linaro.org>
+
+Fixes: 66a625a88174 ("ARM: mm: proc-macros: Add generic proc/cache/tlb struct definition macros")
+Suggested-by: Ard Biesheuvel <ardb@kernel.org>
+Acked-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From eaf6cc7165c9c5aa3c2f9faa03a98598123d0afb Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Mon, 18 Oct 2021 15:30:04 +0100
+Subject: ARM: 9134/1: remove duplicate memcpy() definition
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <lkp@intel.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 44cc6412e66b2b84544eaf2e14cf1764301e2a80 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Mon, 18 Oct 2021 15:30:08 +0100
+Subject: ARM: 9138/1: fix link warning with XIP + frame-pointer
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <keescook@chromium.org>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 1f323127cab086e4fd618981b1e5edc396eaf0f4 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Mon, 18 Oct 2021 15:30:09 +0100
+Subject: ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <mhiramat@kernel.org>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 48ccc8edf5b90622cdc4f8878e0042ab5883e2ca Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+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 <arnd@arndb.de>
+
+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 <arnd@arndb.de>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 792bb6eb862333658bf1bd2260133f0507e2da8d Mon Sep 17 00:00:00 2001
+From: Pavel Begunkov <asml.silence@gmail.com>
+Date: Thu, 18 Feb 2021 22:32:51 +0000
+Subject: io_uring: don't take uring_lock during iowq cancel
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+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: <stable@vger.kernel.org> # 5.5+
+Fixes: c07e6719511e ("io_uring: hold uring_lock while completing failed polled io in io_wq_submit_work()")
+Reported-by: Abaci <abaci@linux.alibaba.com>
+Reported-by: Hao Xu <haoxu@linux.alibaba.com>
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+[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 <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
