Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp920311pxb; Wed, 6 Apr 2022 04:19:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwi3CYq9FiMz2a/YraTQ9S95TZ8/VwIuUZGfUc+4eIQDogz4BF/YzvpKO9ohduixiZhHyso X-Received: by 2002:aa7:88c5:0:b0:4fb:821:4017 with SMTP id k5-20020aa788c5000000b004fb08214017mr8284635pff.22.1649243945307; Wed, 06 Apr 2022 04:19:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649243945; cv=none; d=google.com; s=arc-20160816; b=lfQ8vJ8t6+3nKcAnknJGNapgfyQk4kEDjQvsgjFTo2Cl0lyohn1b6Gg0+Ulc8HHltl d5WjjwVcNDQpgqL69XXR31aFfogUZVL0DnU/U2nY4AQ/q/3jvOVyxEibtY7qeGftWP40 Kf/C0sl6MYS1gvFLnAWl3gp4yTX1+E0cCvDm0Owxt6GnEDb3Uoby05JkBSotgKQzHiRC cEEryYMSMzganCNOfQ2Z8WTwgx1UqqGKIYCzD49AbkGNuLFBc8xtIHHEj6mxYBaVY19F 9JFMU0rNdOnhhg2Uio7XrQkAp6Pw4sQgpWOhLGkZnQqwZhCLwWo9Ail0JmytgnH5EkII vuLg== 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=R8Ixv/siltMNAVa82FFw5Ww2U+cNPa3RwMf+xuPJrsI=; b=v4a3L8DA732shWFMQVBDh+LiDHE0g0JGiy2wuNis6h2Bfk+9txhNBU0JTRbp6MRgZN mWbao7L3sOaU8cYqn8Bus+2xgz5IpXV0V8oJ5HK0qiV39gJblclLey0D/1lkPpsXM3Gz cJGBo/uLEPcEO+4pxqhhi9gRm8BzDAQmDOXtO41ZBZV0LcgTdJuBeTeWy1TvSo8tutaI K3KVR1RD4YEynRpWH+zrBsXcVb7MxBQbBBXwAJREZKHc3Pt6NUvrSPIS5MWL/nu2W7D6 Nb4k8T473iEwZBgkU5CwD9hW/xLBzTdTnuLcj/8Ynj5S8Xk95cTXgcSSNd0P+Hv4m+88 eFsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lnKPSqQ1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id k68-20020a636f47000000b00382246ec31asi15552588pgc.472.2022.04.06.04.19.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 04:19:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lnKPSqQ1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 47D515E40F7; Wed, 6 Apr 2022 02:42:00 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1582551AbiDEXsj (ORCPT + 99 others); Tue, 5 Apr 2022 19:48:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355833AbiDEKWI (ORCPT ); Tue, 5 Apr 2022 06:22:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E51DB9F6C7; Tue, 5 Apr 2022 03:05:10 -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 29C956172B; Tue, 5 Apr 2022 10:05:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A2C6C385A2; Tue, 5 Apr 2022 10:05:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649153109; bh=MSTbhPiz+0gIdLuJbCp8xgfsyCNe3dcUzSOKZ3PzUac=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lnKPSqQ1PP6ZLhBthUQjLUPe+oa9LUZ600hkdiFrBtwtmuHUuZWZyS1fiJMqV6pUT WzEMlaqElnSA/65kRilAWWZJmKRXrNXpIzqOLTBODXniAalUiDaPOpWlReUj9g+gMQ QF/ZWF2nSsUysyCx1dOtyBq2/Isrcbig+b3doFtk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuan-Ying Lee , Catalin Marinas , Matthias Brugger , Chinwen Chang , Nicholas Tang , Yee Lee , Andrew Morton , Linus Torvalds Subject: [PATCH 5.10 078/599] mm/kmemleak: reset tag when compare object pointer Date: Tue, 5 Apr 2022 09:26:12 +0200 Message-Id: <20220405070301.147117364@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070258.802373272@linuxfoundation.org> References: <20220405070258.802373272@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 From: Kuan-Ying Lee commit bfc8089f00fa526dea983844c880fa8106c33ac4 upstream. When we use HW-tag based kasan and enable vmalloc support, we hit the following bug. It is due to comparison between tagged object and non-tagged pointer. We need to reset the kasan tag when we need to compare tagged object and non-tagged pointer. kmemleak: [name:kmemleak&]Scan area larger than object 0xffffffe77076f440 CPU: 4 PID: 1 Comm: init Tainted: G S W 5.15.25-android13-0-g5cacf919c2bc #1 Hardware name: MT6983(ENG) (DT) Call trace: add_scan_area+0xc4/0x244 kmemleak_scan_area+0x40/0x9c layout_and_allocate+0x1e8/0x288 load_module+0x2c8/0xf00 __se_sys_finit_module+0x190/0x1d0 __arm64_sys_finit_module+0x20/0x30 invoke_syscall+0x60/0x170 el0_svc_common+0xc8/0x114 do_el0_svc+0x28/0xa0 el0_svc+0x60/0xf8 el0t_64_sync_handler+0x88/0xec el0t_64_sync+0x1b4/0x1b8 kmemleak: [name:kmemleak&]Object 0xf5ffffe77076b000 (size 32768): kmemleak: [name:kmemleak&] comm "init", pid 1, jiffies 4294894197 kmemleak: [name:kmemleak&] min_count = 0 kmemleak: [name:kmemleak&] count = 0 kmemleak: [name:kmemleak&] flags = 0x1 kmemleak: [name:kmemleak&] checksum = 0 kmemleak: [name:kmemleak&] backtrace: module_alloc+0x9c/0x120 move_module+0x34/0x19c layout_and_allocate+0x1c4/0x288 load_module+0x2c8/0xf00 __se_sys_finit_module+0x190/0x1d0 __arm64_sys_finit_module+0x20/0x30 invoke_syscall+0x60/0x170 el0_svc_common+0xc8/0x114 do_el0_svc+0x28/0xa0 el0_svc+0x60/0xf8 el0t_64_sync_handler+0x88/0xec el0t_64_sync+0x1b4/0x1b8 Link: https://lkml.kernel.org/r/20220318034051.30687-1-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee Reviewed-by: Catalin Marinas Cc: Matthias Brugger Cc: Chinwen Chang Cc: Nicholas Tang Cc: Yee Lee Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/kmemleak.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -787,6 +787,8 @@ static void add_scan_area(unsigned long unsigned long flags; struct kmemleak_object *object; struct kmemleak_scan_area *area = NULL; + unsigned long untagged_ptr; + unsigned long untagged_objp; object = find_and_get_object(ptr, 1); if (!object) { @@ -795,6 +797,9 @@ static void add_scan_area(unsigned long return; } + untagged_ptr = (unsigned long)kasan_reset_tag((void *)ptr); + untagged_objp = (unsigned long)kasan_reset_tag((void *)object->pointer); + if (scan_area_cache) area = kmem_cache_alloc(scan_area_cache, gfp_kmemleak_mask(gfp)); @@ -806,8 +811,8 @@ static void add_scan_area(unsigned long goto out_unlock; } if (size == SIZE_MAX) { - size = object->pointer + object->size - ptr; - } else if (ptr + size > object->pointer + object->size) { + size = untagged_objp + object->size - untagged_ptr; + } else if (untagged_ptr + size > untagged_objp + object->size) { kmemleak_warn("Scan area larger than object 0x%08lx\n", ptr); dump_object_info(object); kmem_cache_free(scan_area_cache, area);