From patchwork Mon Oct 24 11:33:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 10188 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp641531wru; Mon, 24 Oct 2022 13:35:40 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6GNG7G6UvRdWxMNx3aKEuunszWNsAbBJ5kulvMTFq0UrRDtc1o/aDb4NZxMNbwlhHRdv7D X-Received: by 2002:a17:90a:54:b0:212:eb01:1ce with SMTP id 20-20020a17090a005400b00212eb0101cemr14626730pjb.236.1666643739953; Mon, 24 Oct 2022 13:35:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666643739; cv=none; d=google.com; s=arc-20160816; b=YtT2IS89NFyG94Entc4C9h9Tiq1CuFkrHqHKOWG/Dvp1YmKKJBK0dKqwvNzROgVwdX exgSJMmKPIRG/OngdWYWqGNAAl6Q3uPcxOFmO0QOC4BxePl+7BltztBnWCxT3cDHEQJu OaMIsj8s2Rh2000j9I3BMgYcfxLdAslWQfHlc9g5mHRaaRl5m1TY1nv85tvyLguu0kZG /bPLl5kai7itZu6x0bcq5rCU9tZa4WpZuYmbI9wqLgysjFEIA/5FkM3JwcbKSD5rKISx t7/ZettVh28hRGp2zlYYGMKpt4SARcztUfhefJ0r4aTEZzGxouiKew0e/jPTTkh+2j3W gsTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=iNqWz2VwA+6P+/wAELu+n2hy7ZBNUejQElOmwh2ScKE=; b=Eb1QR3/s5OD3UNFoByudpzeO2AYx9D9a+6fijXqui1bAkvhUBXadknEzS0ZehhUxKP YFtIA+aNi677ZWHimJw4NNQZayf4F+IpMzZCq7R0AaU7Xwrtp5N5Og/Hr1B31/ANpBQ2 2RPzgVRQr3QEO2abu4X0UjDK+JldxMEjVqM39NLc0Z64qHhR1Pt7qQX1016ZDeHf9Lbf 1f2//nk6HWVfQDhtpefcINxHtfEaofPBVUuK3FfE0wORxtm1XY8EHYSHCudeC521Imaw fPrmOM+OASUooQxZpVQTf1aEegREWEcOhFSnj9PHNjY1Ys4Y88UYAiBD6HhmJsU63Gok p+WQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qM+bLZKE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v20-20020a170902e8d400b0017a0530a2dbsi441853plg.58.2022.10.24.13.35.23; Mon, 24 Oct 2022 13:35:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qM+bLZKE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234190AbiJXUZh (ORCPT + 99 others); Mon, 24 Oct 2022 16:25:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233302AbiJXUX3 (ORCPT ); Mon, 24 Oct 2022 16:23:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E04701CDCDE; Mon, 24 Oct 2022 11:38:53 -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 BD12161298; Mon, 24 Oct 2022 12:53:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D102EC433C1; Mon, 24 Oct 2022 12:53:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666616030; bh=emIx/+3Q8BsgCf+v6rmowQa5eTKpefi3ZwOFOIBfSkg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qM+bLZKEIX0JyXH4/8PHo5oLDX3b5TbTQwHOSaYs6N7QQaU2MrrP3dQWuTWDf2JoA h/lcfPEGO8NXQU3OkCssnmu+7FFJ6zHoT458IBWdHsXDKyYzcRakvOBbd5A2TS57cU xi7exCvECg91tFj0evR9WLRvvdgDCezSiKc7+ACY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Walleij , Alexander Sverdlin , "Russell King (Oracle)" , Sasha Levin Subject: [PATCH 5.15 475/530] ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n Date: Mon, 24 Oct 2022 13:33:39 +0200 Message-Id: <20221024113106.539687901@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024113044.976326639@linuxfoundation.org> References: <20221024113044.976326639@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747602625959229747?= X-GMAIL-MSGID: =?utf-8?q?1747602625959229747?= 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 4b1619584b23..948ada4a2938 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