All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Lexi Shao <shaolexi@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org, dvyukov@google.com,
	ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com,
	digetx@gmail.com, linus.walleij@linaro.org,
	liuwenliang@huawei.com, nixiaoming@huawei.com, qiuxi1@huawei.com,
	wangkefeng.wang@huawei.com
Subject: Re: [PATCH] ARM: kasan: Fix __get_user_check failure with kasan
Date: Fri, 27 Aug 2021 13:56:01 +0100	[thread overview]
Message-ID: <20210827125601.GT22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210825064650.98162-1-shaolexi@huawei.com>

On Wed, Aug 25, 2021 at 02:46:50PM +0800, Lexi Shao wrote:
> 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.
> 
> 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.

This description doesn't actually make it clear why this is failing in
this case, until one looks at get_futex_value_locked() and realises
that what is actually going on here is:

	*dest = (typeof(*(p))) __r2;

which is why we end up with the store there.

> 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>
> ---
>  arch/arm/include/asm/uaccess.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
> index a13d90206472..a6eb9af74870 100644
> --- 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;							\
> +		__e = __tmp_e;						\

There is no need to re-assign __tmp_e back to __e - you can just return
__tmp_e here.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-08-27 12:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25  6:46 [PATCH] ARM: kasan: Fix __get_user_check failure with kasan Lexi Shao
2021-08-25  9:06 ` Dmitry Osipenko
2021-08-28  3:26   ` Lexi Shao
2021-08-27 12:39 ` Kefeng Wang
2021-08-27 12:56 ` Russell King (Oracle) [this message]
2021-08-28  2:21   ` Lexi Shao
2021-08-28  2:25   ` [PATCH v2] " Lexi Shao
2021-08-31  9:51     ` Dmitry Osipenko
2021-09-20 17:07       ` Dmitry Osipenko
2021-09-01  7:05     ` Kefeng Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210827125601.GT22278@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andreyknvl@gmail.com \
    --cc=digetx@gmail.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=liuwenliang@huawei.com \
    --cc=nixiaoming@huawei.com \
    --cc=qiuxi1@huawei.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=shaolexi@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.