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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_SANE_2 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 876CCC433EF for ; Thu, 23 Sep 2021 11:19:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6F99660EC0 for ; Thu, 23 Sep 2021 11:19:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240608AbhIWLVE (ORCPT ); Thu, 23 Sep 2021 07:21:04 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:56650 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S240493AbhIWLVD (ORCPT ); Thu, 23 Sep 2021 07:21:03 -0400 X-UUID: 9b253f948c5b4dac8dd1a58292d989df-20210923 X-UUID: 9b253f948c5b4dac8dd1a58292d989df-20210923 Received: from mtkcas11.mediatek.inc [(172.21.101.40)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1948045060; Thu, 23 Sep 2021 19:19:29 +0800 Received: from mtkexhb02.mediatek.inc (172.21.101.103) by mtkmbs06n1.mediatek.inc (172.21.101.129) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Sep 2021 19:19:28 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkexhb02.mediatek.inc (172.21.101.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Sep 2021 19:19:28 +0800 Received: from mtksdccf07 (172.21.84.99) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 23 Sep 2021 19:19:22 +0800 Message-ID: <5f7a9ed1dabba25596c38a8e7c32ee5750b80459.camel@mediatek.com> Subject: Re: [PATCH] scs: Release kasan vmalloc poison in scs_free process From: Kuan-Ying Lee To: , CC: , , "Matthias Brugger" , Will Deacon , "Sami Tolvanen" , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" Date: Thu, 23 Sep 2021 19:19:21 +0800 In-Reply-To: <20210923095316.13867-1-yee.lee@mediatek.com> References: <20210923095316.13867-1-yee.lee@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2021-09-23 at 17:53 +0800, yee.lee@mediatek.com wrote: > From: Yee Lee > > Since scs allocation has been moved to vmalloc region, the > shadow stack is protected by kasan_posion_vmalloc. > However, the vfree_atomic operation needs to access > its context for scs_free process and causes kasan error > as the dump info below. > > This patch Adds kasan_unpoison_vmalloc() before vfree_atomic, > which aligns to the prior flow as using kmem_cache. > The vmalloc region will go back posioned in the following > vumap() operations. > > ================================================================== > BUG: KASAN: vmalloc-out-of-bounds in llist_add_batch+0x60/0xd4 > Write of size 8 at addr ffff8000100b9000 by task kthreadd/2 > > CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.15.0-rc2-11681-(skip) > Hardware name: linux,dummy-virt (DT) > Call trace: > dump_backtrace+0x0/0x43c > show_stack+0x1c/0x2c > dump_stack_lvl+0x68/0x84 > print_address_description+0x80/0x394 > kasan_report+0x180/0x1dc > __asan_report_store8_noabort+0x48/0x58 > llist_add_batch+0x60/0xd4 > vfree_atomic+0x60/0xe0 > scs_free+0x1dc/0x1fc > scs_release+0xa4/0xd4 > free_task+0x30/0xe4 > __put_task_struct+0x1ec/0x2e0 > delayed_put_task_struct+0x5c/0xa0 > rcu_do_batch+0x62c/0x8a0 > rcu_core+0x60c/0xc14 > rcu_core_si+0x14/0x24 > __do_softirq+0x19c/0x68c > irq_exit+0x118/0x2dc > handle_domain_irq+0xcc/0x134 > gic_handle_irq+0x7c/0x1bc > call_on_irq_stack+0x40/0x70 > do_interrupt_handler+0x78/0x9c > el1_interrupt+0x34/0x60 > el1h_64_irq_handler+0x1c/0x2c > el1h_64_irq+0x78/0x7c > _raw_spin_unlock_irqrestore+0x40/0xcc > sched_fork+0x4f0/0xb00 > copy_process+0xacc/0x3648 > kernel_clone+0x168/0x534 > kernel_thread+0x13c/0x1b0 > kthreadd+0x2bc/0x400 > ret_from_fork+0x10/0x20 > > Memory state around the buggy address: > ffff8000100b8f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > ffff8000100b8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > >ffff8000100b9000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > ^ > ffff8000100b9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > ffff8000100b9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > ================================================================== > > CC: Matthias Brugger > CC: Will Deacon > CC: Sami Tolvanen > Signed-off-by: Yee Lee > --- > kernel/scs.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/scs.c b/kernel/scs.c > index e2a71fc82fa0..25c0d8e416e6 100644 > --- a/kernel/scs.c > +++ b/kernel/scs.c > @@ -68,6 +68,7 @@ void scs_free(void *s) > > __scs_account(s, -1); > > + kasan_unpoison_vmalloc(s, SCS_SIZE); > /* > * We cannot sleep as this can be called in interrupt context, > * so use this_cpu_cmpxchg to update the cache, and > vfree_atomic I'm not sure if we need to add kasan_unpoison_vmalloc() and kasan_poison_vmalloc() in this file. As far as I know, vmalloc() and vfree() will do these two functions.