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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B579EC43334 for ; Mon, 20 Jun 2022 06:58:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 244A06B0071; Mon, 20 Jun 2022 02:58:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F4596B0073; Mon, 20 Jun 2022 02:58:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BC748E0001; Mon, 20 Jun 2022 02:58:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EE2CF6B0071 for ; Mon, 20 Jun 2022 02:58:50 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B8028BC1 for ; Mon, 20 Jun 2022 06:58:50 +0000 (UTC) X-FDA: 79597711620.28.475CC28 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf17.hostedemail.com (Postfix) with ESMTP id 65EE640009 for ; Mon, 20 Jun 2022 06:58:50 +0000 (UTC) Received: by mail-lj1-f179.google.com with SMTP id c30so10812206ljr.9 for ; Sun, 19 Jun 2022 23:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AQB+fC1Ry/DquRxnS+KzvjL21WPwMtczsitm2G5gP3c=; b=C6STohw//IykeHfdXURwO7799cZQ18Nlm4+ldNTxKcSx4vWR9qvXRDpNIyLD54ex+u YQaHM9Dk3m3PFonrqpKPGK4aXzVGcwXzET6FCFQ7fuhgEKTsZUUlQQRDIga7/FPAAPif T7aHWbs9y1syUqemR2x5rsBIXls0dDsco1sc0ViUttb6Subl4obOXmpQRiXukK3mstzx 0ixOa82cyx/GO2gBNQDoGrF+aabZ4+9m1Jw6vF8wOrgUYRacwXNxcLoo7nybOqebcp30 jvxOyKLwul1nBQs1mCZRgXIPH1WfidMky4XGF2WWs0hfzbTOk7wiG4IEmwAdrDuOhNgm QveQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AQB+fC1Ry/DquRxnS+KzvjL21WPwMtczsitm2G5gP3c=; b=wm0nyYiGz/mhvp2H/hckiXMEhVlKgDOLihEPt6ppJSe7VkWo/VGW26h7DE3gTD0qjC q4jreJBQz342rGDL7iqeFFXzw6EL8h2huPAGiIWyYCF+ED7uPhScbpIEnQCviRhqER86 UCUtlGciKWC7oveQ/0IPiH3qgja7p9FrvqEqZnFlpCkPgXCZjbTRBrSYgRs4HfPMngm1 yoG5wcLK/3Ag7uLcwDXt4FM/CiMrw5TbjtfSi4zN+k/4U1b2Udh4F96XOvtuKiX2wsys V+mf/5LFNhQOtvmpey3amYkZ0cmv+M1+iXNLQ76s3epnn10dtn7VPVqWzpoxNIpc6auO 8QUg== X-Gm-Message-State: AJIora8s08bA2ez2QhZy4eG1nOZzHXK1HInAd4aCPYaKwEgsTx1/NtHd FJOmPLn2nHGNtJq5vuJBa8aLRUI3w8HM/fiTb+4= X-Google-Smtp-Source: AGRyM1sPhDhnvBU5edUFq2ix7rPoHJrM6i6s1+9KG/pPuqwhUjaMgKKUm7FDpj0w6+x1EHx4TPQdH5qLVvlYUE1JEx0= X-Received: by 2002:a2e:b0fc:0:b0:255:6f92:f9d4 with SMTP id h28-20020a2eb0fc000000b002556f92f9d4mr11174955ljl.92.1655708328432; Sun, 19 Jun 2022 23:58:48 -0700 (PDT) MIME-Version: 1.0 References: <1653447164-15017-1-git-send-email-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Mon, 20 Jun 2022 14:58:18 +0800 Message-ID: Subject: Re: [PATCH] mm: fix racing of vb->va when kasan enabled To: Uladzislau Rezki Cc: "zhaoyang.huang" , Andrew Morton , "open list:MEMORY MANAGEMENT" , LKML , Ke Wang , hch@lst.de Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655708330; a=rsa-sha256; cv=none; b=K9nmStKfkeNHybIThPcbZFyaEoi79uJGn6QmJ+i1+uTBjhjm0Tbjx4gBKwJwEwhHb12nnk x9rKEs3chRTT8W1dQIrEmykwaD+9TRfFygNiMsQTJeRTX971Pxo8w81gbXDH1EleTS42ey R6oN9tSJtEmi8NfZHiCIavgfdIM70JA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="C6STohw/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655708330; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AQB+fC1Ry/DquRxnS+KzvjL21WPwMtczsitm2G5gP3c=; b=O9Nf+y+HXL8TtteF+NJGwfjwNxoVFqnz4dJketHQHZOdwq8J5sIXppOsoGw/Jq+sW51ZoP 5WpvqUhAdsLmy+jnyYmC8M9h3yHn3BEf0JCxTR7Z0FL6htjAEWwr2kAV9hzcAHtNid2/HA O4GXY0Vr5bNDLAFuODIUp8u30WEXZFY= Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="C6STohw/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-Stat-Signature: bc9kuhyxxyipuxzpxpidxeic51w4uz8e X-Rspamd-Queue-Id: 65EE640009 X-Rspam-User: X-Rspamd-Server: rspam03 X-HE-Tag: 1655708330-881184 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jun 20, 2022 at 5:03 AM Uladzislau Rezki wrote: > > > On Thu, May 26, 2022 at 10:18 AM zhaoyang.huang > > wrote: > > > > > > From: Zhaoyang Huang > > > > > > Accessing to vb->va could be deemed as use after free when KASAN is > > > enabled like bellowing. Fix it by expanding the mutex's range. > > > > > > [ 20.232335] ================================================================== > > > [ 20.232365] BUG: KASAN: use-after-free in _vm_unmap_aliases+0x164/0x364 > > > [ 20.232376] Read of size 8 at addr ffffff80d84af780 by task modprobe/300 > > > [ 20.232380] > > > [ 20.232395] CPU: 5 PID: 300 Comm: modprobe Tainted: G S C O 5.4.161-android12-9-03238-gd43329d103de-ab20547 #1 > > > [ 20.232401] Hardware name: Spreadtrum UMS512-1H10 SoC (DT) > > > [ 20.232407] Call trace: > > > [ 20.232419] dump_backtrace+0x0/0x2b4 > > > [ 20.232428] show_stack+0x24/0x30 > > > [ 20.232443] dump_stack+0x15c/0x1f4 > > > [ 20.232455] print_address_description+0x88/0x568 > > > [ 20.232465] __kasan_report+0x1b8/0x1dc > > > [ 20.232474] kasan_report+0x10/0x18 > > > [ 20.232486] __asan_report_load8_noabort+0x1c/0x24 > > > [ 20.232495] _vm_unmap_aliases+0x164/0x364 > > > [ 20.232505] vm_unmap_aliases+0x20/0x28 > > > [ 20.232516] change_memory_common+0x2c4/0x3ec > > > [ 20.232524] set_memory_ro+0x30/0x3c > > > [ 20.232539] module_enable_ro+0x144/0x3f0 > > > [ 20.232547] load_module+0x54c0/0x8248 > > > [ 20.232555] __se_sys_finit_module+0x174/0x1b0 > > > [ 20.232564] __arm64_sys_finit_module+0x78/0x88 > > > [ 20.232573] el0_svc_common+0x19c/0x354 > > > [ 20.232581] el0_svc_handler+0x48/0x54 > > > [ 20.232591] el0_svc+0x8/0xc > > > [ 20.232595] > > > [ 20.232602] Allocated by task 297: > > > [ 20.232615] __kasan_kmalloc+0x130/0x1f8 > > > [ 20.232625] kasan_slab_alloc+0x14/0x1c > > > [ 20.232638] kmem_cache_alloc+0x1dc/0x394 > > > [ 20.232648] alloc_vmap_area+0xb4/0x1630 > > > [ 20.232657] vm_map_ram+0x3ac/0x768 > > > [ 20.232671] z_erofs_decompress_generic+0x2f0/0x844 > > > [ 20.232681] z_erofs_decompress+0xa8/0x594 > > > [ 20.232692] z_erofs_decompress_pcluster+0xeb4/0x1458 > > > [ 20.232702] z_erofs_vle_unzip_wq+0xe4/0x140 > > > [ 20.232715] process_one_work+0x5c0/0x10ac > > > [ 20.232724] worker_thread+0x888/0x1128 > > > [ 20.232733] kthread+0x290/0x304 > > > [ 20.232744] ret_from_fork+0x10/0x18 > > > [ 20.232747] > > > [ 20.232752] Freed by task 51: > > > [ 20.232762] __kasan_slab_free+0x1a0/0x270 > > > [ 20.232772] kasan_slab_free+0x10/0x1c > > > [ 20.232781] slab_free_freelist_hook+0xd0/0x1ac > > > [ 20.232792] kmem_cache_free+0x110/0x368 > > > [ 20.232803] __purge_vmap_area_lazy+0x524/0x13e4 > > > [ 20.232813] _vm_unmap_aliases+0x290/0x364 > > > [ 20.232822] __vunmap+0x45c/0x5c4 > > > [ 20.232831] vfree+0x74/0x16c > > > [ 20.232841] module_memfree+0x44/0x7c > > > [ 20.232850] do_free_init+0x5c/0xac > > > [ 20.232860] process_one_work+0x5c0/0x10ac > > > [ 20.232869] worker_thread+0xb3c/0x1128 > > > [ 20.232877] kthread+0x290/0x304 > > > [ 20.232887] ret_from_fork+0x10/0x18 > > > > > > Signed-off-by: Zhaoyang Huang > > > --- > > > mm/vmalloc.c | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > index d2a00ad..028d65a 100644 > > > --- a/mm/vmalloc.c > > > +++ b/mm/vmalloc.c > > > @@ -2081,7 +2081,7 @@ static void _vm_unmap_aliases(unsigned long start, unsigned long end, int flush) > > > return; > > > > > > might_sleep(); > > > - > > > + mutex_lock(&vmap_purge_lock); > > > for_each_possible_cpu(cpu) { > > > struct vmap_block_queue *vbq = &per_cpu(vmap_block_queue, cpu); > > > struct vmap_block *vb; > > > @@ -2106,7 +2106,6 @@ static void _vm_unmap_aliases(unsigned long start, unsigned long end, int flush) > > > rcu_read_unlock(); > > > } > > > > > > - mutex_lock(&vmap_purge_lock); > > > purge_fragmented_blocks_allcpus(); > > > if (!__purge_vmap_area_lazy(start, end) && flush) > > > flush_tlb_kernel_range(start, end); > > > -- > > > 1.9.1 > > > > > > Is it easy to reproduce? If so could you please describe the steps? As i see > the freeing of the "vb" is RCU safe whereas vb->va is not. But from the first > glance i do not see how it can accessed twice. Hm.. It was raised from a monkey test on A13_k515 system and got 1/20 pcs failed. IMO, vb->va which out of vmap_purge_lock protection could race with a concurrent ra freeing within __purge_vmap_area_lazy. > > -- > Uladzislau Rezki