From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7960D28D8FD; Mon, 25 Aug 2025 20:27:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756153681; cv=none; b=p+1yZWPOX8ukpteDa9LH9k9dOKr7TB0A82pZt9H2dm2sFh9cUUd28ijzwyLk4ws+4gv5BCuZhMGJbSD17JiS0kwqOZRD+dCOGt4ojTXFnAIy6S5DK+dt2ik0hctEHt3v3OU5h4meTLsZR3i4ClZu36YgKKTHTdBnEqVtneHXyxw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756153681; c=relaxed/simple; bh=dMA5jYCjV4+NamgNRk8yI8/DC0XoZzSYJsm5xOSYSXU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OLbhpLco4hvNIuEFmQywpZCdyVr11hBvKmGbqKCnI+KELSwf3dVNrjTS7tF9fCMIPqMT6JZwqs61iYSwJiVeMx2yCJdFFXEgdIW/qq97dNn7w6JBn8D5lxy9ctup4wsxd0D+pAz/teINzE3Flzwyex2XoWoCSvU1MYb51aL4W7A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=d4KMRWva; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="d4KMRWva" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1756153679; x=1787689679; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=dMA5jYCjV4+NamgNRk8yI8/DC0XoZzSYJsm5xOSYSXU=; b=d4KMRWva4KrqDkvN5CHqErgeKpKJ7sTPaS0N5OBSoOrQVue0G6OyBSTY peILGEWv/WytmuLNQB/OS+M/KD0jV2TbVYSTz02v1vIgFCBaGAW2pPSQM 0O6Fobd1TuTqXDfyEFVy3gkzhw01ep3yhBP/SWwKlgNotDQ8cYU5x6N2X Tbb+6Zh2GJdqNAqm4W51JtIJzLrIXjpbkM3OOO0CIS2CrcKYf78qZelZt GfBM/OcpmzJbZhsEzhLpA2F+YMTkpW/R6KSVPO+VOIjFfNny3y3GbY3De 607YtCgWdoLY/uq0Z62+IAFTkmnRhge+RZ7bARH1ZCUJqQHMW/+Iij1Ml A==; X-CSE-ConnectionGUID: 9c8oeNucRACH7VmAHM4E8w== X-CSE-MsgGUID: thgVKcTTQKecQOgLSIIgfw== X-IronPort-AV: E=McAfee;i="6800,10657,11533"; a="68970544" X-IronPort-AV: E=Sophos;i="6.18,214,1751266800"; d="scan'208";a="68970544" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2025 13:27:58 -0700 X-CSE-ConnectionGUID: TjWS6R7AR16c56RIZHi+hw== X-CSE-MsgGUID: 97rsnWJETkOP5iPCSk+S2Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,214,1751266800"; d="scan'208";a="169780379" Received: from bergbenj-mobl1.ger.corp.intel.com (HELO wieczorr-mobl1.intel.com) ([10.245.245.6]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2025 13:27:38 -0700 From: Maciej Wieczor-Retman To: sohil.mehta@intel.com, baohua@kernel.org, david@redhat.com, kbingham@kernel.org, weixugc@google.com, Liam.Howlett@oracle.com, alexandre.chartre@oracle.com, kas@kernel.org, mark.rutland@arm.com, trintaeoitogc@gmail.com, axelrasmussen@google.com, yuanchu@google.com, joey.gouly@arm.com, samitolvanen@google.com, joel.granados@kernel.org, graf@amazon.com, vincenzo.frascino@arm.com, kees@kernel.org, ardb@kernel.org, thiago.bauermann@linaro.org, glider@google.com, thuth@redhat.com, kuan-ying.lee@canonical.com, pasha.tatashin@soleen.com, nick.desaulniers+lkml@gmail.com, vbabka@suse.cz, kaleshsingh@google.com, justinstitt@google.com, catalin.marinas@arm.com, alexander.shishkin@linux.intel.com, samuel.holland@sifive.com, dave.hansen@linux.intel.com, corbet@lwn.net, xin@zytor.com, dvyukov@google.com, tglx@linutronix.de, scott@os.amperecomputing.com, jason.andryuk@amd.com, morbo@google.com, nathan@kernel.org, lorenzo.stoakes@oracle.com, mingo@redhat.com, brgerst@gmail.com, kristina.martsenko@arm.com, bigeasy@linutronix.de, luto@kernel.org, jgross@suse.com, jpoimboe@kernel.org, urezki@gmail.com, mhocko@suse.com, ada.coupriediaz@arm.com, hpa@zytor.com, maciej.wieczor-retman@intel.com, leitao@debian.org, peterz@infradead.org, wangkefeng.wang@huawei.com, surenb@google.com, ziy@nvidia.com, smostafa@google.com, ryabinin.a.a@gmail.com, ubizjak@gmail.com, jbohac@suse.cz, broonie@kernel.org, akpm@linux-foundation.org, guoweikang.kernel@gmail.com, rppt@kernel.org, pcc@google.com, jan.kiszka@siemens.com, nicolas.schier@linux.dev, will@kernel.org, andreyknvl@gmail.com, jhubbard@nvidia.com, bp@alien8.de Cc: x86@kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-kbuild@vger.kernel.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH v5 07/19] mm: x86: Untag addresses in EXECMEM_ROX related pointer arithmetic Date: Mon, 25 Aug 2025 22:24:32 +0200 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARCH_HAS_EXECMEM_ROX was re-enabled in x86 at Linux 6.14 release. Related code has multiple spots where page virtual addresses end up used as arguments in arithmetic operations. Combined with enabled tag-based KASAN it can result in pointers that don't point where they should or logical operations not giving expected results. vm_reset_perms() calculates range's start and end addresses using min() and max() functions. To do that it compares pointers but some are not tagged - addr variable is, start and end variables aren't. within() and within_range() can receive tagged addresses which get compared to untagged start and end variables. Reset tags in addresses used as function arguments in min(), max(), within(). execmem_cache_add() adds tagged pointers to a maple tree structure, which then are incorrectly compared when walking the tree. That results in different pointers being returned later and page permission violation errors panicking the kernel. Reset tag of the address range inserted into the maple tree inside execmem_cache_add(). Signed-off-by: Maciej Wieczor-Retman --- Changelog v5: - Remove the within_range() change. - arch_kasan_reset_tag -> kasan_reset_tag. Changelog v4: - Add patch to the series. mm/execmem.c | 2 +- mm/vmalloc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/execmem.c b/mm/execmem.c index 0822305413ec..f7b7bdacaec5 100644 --- a/mm/execmem.c +++ b/mm/execmem.c @@ -186,7 +186,7 @@ static DECLARE_WORK(execmem_cache_clean_work, execmem_cache_clean); static int execmem_cache_add_locked(void *ptr, size_t size, gfp_t gfp_mask) { struct maple_tree *free_areas = &execmem_cache.free_areas; - unsigned long addr = (unsigned long)ptr; + unsigned long addr = (unsigned long)kasan_reset_tag(ptr); MA_STATE(mas, free_areas, addr - 1, addr + 1); unsigned long lower, upper; void *area = NULL; diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 6dbcdceecae1..c93893fb8dd4 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3322,7 +3322,7 @@ static void vm_reset_perms(struct vm_struct *area) * the vm_unmap_aliases() flush includes the direct map. */ for (i = 0; i < area->nr_pages; i += 1U << page_order) { - unsigned long addr = (unsigned long)page_address(area->pages[i]); + unsigned long addr = (unsigned long)kasan_reset_tag(page_address(area->pages[i])); if (addr) { unsigned long page_size; -- 2.50.1