From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F11CC432BE for ; Fri, 27 Aug 2021 12:58:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BE6FB60F4F for ; Fri, 27 Aug 2021 12:58:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BE6FB60F4F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=aIp79uYLQZhi+7mtopLXW7t6B7iyJkN9bBHq2E74srM=; b=pkzBzpqIYd+zsX QBoKnFtDvJUHZzKBT81NSKw7wTDoy21AXJSk/pH5JteuSgWBH67MUWO2ANF5WFwYLTzz8wkT2Ij4k FwQinWUMJKKx3M5zyjBiee7FSEBJfrAChsH1W/NtSynOWb0Q1XLFBERDw8VqRKjmm6BYpBjWAGytU 4Zl8Sqt8V4z1kFWZ2fo3XKhDzPPv6aNMWBstrYvHQCiK89TfXBC0XMx+Ma2d40x2+nPPGX+q9zJ34 Zr99iwp5Mmh4dsCRFaAR+alevPEshpoTwXmJ11k6HQghL6Wn3ZAjCv3Hoqwgy+I3v+pSzmF+Qxt9N xNtINY3i5g+FRihqM0AA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJbP5-00CSXZ-By; Fri, 27 Aug 2021 12:56:15 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJbOy-00CSWm-NJ for linux-arm-kernel@lists.infradead.org; Fri, 27 Aug 2021 12:56:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pIeR53qBH9fBS/JugyJxOvlJlLEozelXlHnwDOjq+LA=; b=uLYH1cMOzkc0B7CUs5hHV3B0S nggsgYeOKC/JW6yz/rDpyUVD2EpSnSdWWtm1LIeBOijE7YxY13g50hgHmJYHFfrkFhgZKMKRqNNcb ckqPsUQVuOEVPKmyLH5zSDn7YUBpgBKf3TDn1cMWGGim5wboahyFVJDErvDhMhYnqKug0RTvSvz3e eOv/FlTy9y3uZePsWpPhV8sJ6R/uoF52JMJF2WhhH9suWu34UgiPE7aw4lpkx4pF/4Hsd3O2nRUvo 1BB4+PIElnqUi5BMdmmkPayTg9vct4224MDk9aMD+e4n+j9WGVC4MxEQgY5oUPMzVtGsQxYlhvn7P LpRPlBL4g==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:47750) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mJbOt-00016S-S6; Fri, 27 Aug 2021 13:56:03 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1mJbOr-0001ny-5D; Fri, 27 Aug 2021 13:56:01 +0100 Date: Fri, 27 Aug 2021 13:56:01 +0100 From: "Russell King (Oracle)" To: Lexi Shao 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 Message-ID: <20210827125601.GT22278@shell.armlinux.org.uk> References: <20210825064650.98162-1-shaolexi@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210825064650.98162-1-shaolexi@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210827_055608_953824_0D685D8A X-CRM114-Status: GOOD ( 25.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > --- > 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