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 D47EEC43334 for ; Sun, 19 Jun 2022 21:03:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C5C26B0071; Sun, 19 Jun 2022 17:03:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 04D566B0072; Sun, 19 Jun 2022 17:03:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E30856B0073; Sun, 19 Jun 2022 17:03:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D08306B0071 for ; Sun, 19 Jun 2022 17:03:50 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A22C420D6D for ; Sun, 19 Jun 2022 21:03:50 +0000 (UTC) X-FDA: 79596212220.05.F735DD8 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf24.hostedemail.com (Postfix) with ESMTP id 4E708180014 for ; Sun, 19 Jun 2022 21:03:50 +0000 (UTC) Received: by mail-lf1-f44.google.com with SMTP id i18so705869lfu.8 for ; Sun, 19 Jun 2022 14:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=stFDvED2lOpvuI58rxdqCsj7yH4mZGe0nB/hKuOE8cw=; b=Q3d1CzB2/awpEEBbKHzPtDLoIR98Fyv8QWVxmR+hsCJ7TKVDW+QOg+7HP/Q0ZaBXXx BY7/FAi+1v2fUrmMSazSwZSUdkRoRnlZ/ROtVMhUFRzqnwoP568hHLCevS1Pb5suCOCS 6uL36A8fHBzMVomC5hwsY7J8fmuk8XTwF+qr4eacEl1EBKtI/ryW6zycP89IruAQXnmr Qp9XRICc/Ql9OWsQ8BB//nY+5QCqmAtyCgewYPC3Upit/jejTA0W0TYwTIgIs9SHYx/3 /cC8v82VCmXB5Phbeq0xe3wh57d/vmD9enqhFmCZ4JXFR9rVMyVXEoiBQ8X/1ETbg0Kr /M3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=stFDvED2lOpvuI58rxdqCsj7yH4mZGe0nB/hKuOE8cw=; b=YS9h1XfgCGgxBQZxSn3MjYpKMyzt031V2LcURBmDFGAXvIP0f4uwGVhj1CQbezx1gi BGdlHqkoDnGfRS224kD+Cj2fMPuCpZZl5e7sbx6NKsvX+9QV2SvU5bl7ZxyuZ326Hvte ty6zPoVn0gqGfeQ+t0XIGtOddz0Xy7UkRaDWKBD5LsLX2bgL7IfLTa63bdv82W5UuPGU 9yKM0Kea+BqFtAAaTS4pYcq7Tph2ZMa3+clw8EcN9tv6kOCb3HCGAMsFU2CPh5gBYGTY 8woVN98BXUpekM/MATzqY4fWZGdi+eXLtNbBmVZOvrlu9Bwch2RK2nsnxRGGvbGaHRwe QPQg== X-Gm-Message-State: AJIora/KRMLzgwZD4M08nkBQFFKn7Z8NUkscNTmQuUjPRovgdMR+QvNM K1jiDnjFNV3dvQLPy/I1Mvw= X-Google-Smtp-Source: AGRyM1u/bJkWel/g/09LJ7hvw2H/TeoMFA0EHDnebY1qMFMIVO2d5rinjOmJYO2lPqYQ97iSc1KEqg== X-Received: by 2002:a05:6512:238f:b0:47f:6fc3:f268 with SMTP id c15-20020a056512238f00b0047f6fc3f268mr1026393lfv.148.1655672628464; Sun, 19 Jun 2022 14:03:48 -0700 (PDT) Received: from pc638.lan ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id s9-20020a056512214900b004790b5a0b22sm1490923lfr.239.2022.06.19.14.03.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jun 2022 14:03:47 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Sun, 19 Jun 2022 23:03:45 +0200 To: "zhaoyang.huang" Cc: "zhaoyang.huang" , Andrew Morton , Zhaoyang Huang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com, hch@lst.de Subject: Re: [PATCH] mm: fix racing of vb->va when kasan enabled Message-ID: References: <1653447164-15017-1-git-send-email-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655672630; a=rsa-sha256; cv=none; b=wg4dSuhSKYKLHDPdFAsCM24x2/Zah4LXH1B7Qib+OZYbP0rNO3eXmBJmPGRo5WsCZseLjk Gpq4EImKZiU92X0rYbp+M6+bkbVeGJ0DZdtW1Pc5QX2+a9LOHrgypVl/1EnTTed+FZ6Oxa MyVdV0yRJv7T92Gybo8qlwu0pU/skbI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655672630; 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=stFDvED2lOpvuI58rxdqCsj7yH4mZGe0nB/hKuOE8cw=; b=DASqDgvwv/wn8/cQnOhhUYs/rFMNPPGStv5RQRULxdqUya1vpL+vwQhzXRofLtjuCXV4Y4 Mnaa8S8Nr5pqwlPhLokYGxmnpDCAiP6Xq4KO5h67kgNsqqoU7Bttk851GcmOJOUaPn0SME g9Tl2XdmjpU0yCrFa9gQ9ML8hUMxBJ0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Q3d1CzB2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=urezki@gmail.com Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Q3d1CzB2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=urezki@gmail.com X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4E708180014 X-Stat-Signature: 4s4p9a1um5qmgmmux9h8h6eaukgc9b18 X-HE-Tag: 1655672630-986310 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > 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.. -- Uladzislau Rezki