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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9629DC4332F for ; Tue, 11 Oct 2022 15:00:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230498AbiJKPAS (ORCPT ); Tue, 11 Oct 2022 11:00:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231283AbiJKO6p (ORCPT ); Tue, 11 Oct 2022 10:58:45 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE6D498C8B; Tue, 11 Oct 2022 07:52:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5436A611AC; Tue, 11 Oct 2022 14:52:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3277C43143; Tue, 11 Oct 2022 14:52:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665499951; bh=TvPV0O+Kmdv7gIYS3XYbXJAt0YZQk0UJbeoYiMjrHmI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QcMlDUGyT6WakJg/WaVLieaFKDogKb83td/f9CKsJnabq2lWj+zX3dQwQf2AtbT0W tyJiTMqiC+u1mLxv5L7/7gUpjoXEBfGxTUbMq5su4887f2TrB58aLVvZkyuvnhVWNy e2S6jN6vkjlBJh0yGPYkslNmJH2SsLFhFMjJuiUaRmSaIpK8JY2Qsre21ECOW4wKjX Bil81d7wKCM93T1keyhmiWch8N0Evg26ee8RAB8F4aky6QvtK3/SG5Dwv2ZQWkbvCl t430FDgyR7uerCHyfzqHjLozbBx/GC4s8PfbIk6NT3ZTrzCrngS0HswKKDwjYizPF/ Jkb6UiVvkkehQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alex Sverdlin , Linus Walleij , Russell King , Sasha Levin , aryabinin@virtuozzo.com, linux@armlinux.org.uk, kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org Subject: [PATCH AUTOSEL 5.19 39/40] ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n Date: Tue, 11 Oct 2022 10:51:28 -0400 Message-Id: <20221011145129.1623487-39-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20221011145129.1623487-1-sashal@kernel.org> References: <20221011145129.1623487-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Alex Sverdlin [ Upstream commit 823f606ab6b4759a1faf0388abcf4fb0776710d2 ] In case CONFIG_KASAN_VMALLOC=y kasan_populate_vmalloc() allocates the shadow pages dynamically. But even worse is that kasan_release_vmalloc() releases them, which is not compatible with create_mapping() of MODULES_VADDR..MODULES_END range: BUG: Bad page state in process kworker/9:1 pfn:2068b page:e5e06160 refcount:0 mapcount:0 mapping:00000000 index:0x0 flags: 0x1000(reserved) raw: 00001000 e5e06164 e5e06164 00000000 00000000 00000000 ffffffff 00000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set bad because of flags: 0x1000(reserved) Modules linked in: ip_tables CPU: 9 PID: 154 Comm: kworker/9:1 Not tainted 5.4.188-... #1 Hardware name: LSI Axxia AXM55XX Workqueue: events do_free_init unwind_backtrace show_stack dump_stack bad_page free_pcp_prepare free_unref_page kasan_depopulate_vmalloc_pte __apply_to_page_range apply_to_existing_page_range kasan_release_vmalloc __purge_vmap_area_lazy _vm_unmap_aliases.part.0 __vunmap do_free_init process_one_work worker_thread kthread Reviewed-by: Linus Walleij Signed-off-by: Alexander Sverdlin Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin --- arch/arm/mm/kasan_init.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c index 5ad0d6c56d56..29d7233e5ad2 100644 --- a/arch/arm/mm/kasan_init.c +++ b/arch/arm/mm/kasan_init.c @@ -264,12 +264,17 @@ void __init kasan_init(void) /* * 1. The module global variables are in MODULES_VADDR ~ MODULES_END, - * so we need to map this area. + * so we need to map this area if CONFIG_KASAN_VMALLOC=n. With + * VMALLOC support KASAN will manage this region dynamically, + * refer to kasan_populate_vmalloc() and ARM's implementation of + * module_alloc(). * 2. PKMAP_BASE ~ PKMAP_BASE+PMD_SIZE's shadow and MODULES_VADDR * ~ MODULES_END's shadow is in the same PMD_SIZE, so we can't * use kasan_populate_zero_shadow. */ - create_mapping((void *)MODULES_VADDR, (void *)(PKMAP_BASE + PMD_SIZE)); + if (!IS_ENABLED(CONFIG_KASAN_VMALLOC) && IS_ENABLED(CONFIG_MODULES)) + create_mapping((void *)MODULES_VADDR, (void *)(MODULES_END)); + create_mapping((void *)PKMAP_BASE, (void *)(PKMAP_BASE + PMD_SIZE)); /* * KAsan may reuse the contents of kasan_early_shadow_pte directly, so -- 2.35.1