From nobody Thu Apr 2 01:50:51 2026 Received: from mail-244116.protonmail.ch (mail-244116.protonmail.ch [109.224.244.116]) (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 A3F532E7162 for ; Mon, 30 Mar 2026 14:33:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.116 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774881239; cv=none; b=QMacGGGjYGE/TcQxzV5VF4XdZlGTNtis4TY3zEitqyNX/W9cgkxwnpBP5aOH/haO6gjkPM2mLvW6kO68cqSKXPEFiXqTFyAFGh8jO5EtAcVVN3O1b189XHwZlPm5PVg5JT+oCgxJi3UxQcm4vwxt05Rv6s3UyemyiXw3J71UqZU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774881239; c=relaxed/simple; bh=rYcYU9ZWL1vy2pbB3vmo9XiRTrpuTtXXHyDEYzp0q5c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OOpN2GngRz2RsvMtENNxXBl4G7aqtMUiiZgwPO738nA6AS07nLF98ME6+blG+ra3lqjlxTaSm9dBR6AXUQkzvJC6LKuvUSeBW2oPNWEXhHekiNw+dM+w/mOeOelF1MWQ61wdw6EmhpL5VyEe7xXKqhMkHqyRaeGw6+Ga9bE8wPc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=od67eMOl; arc=none smtp.client-ip=109.224.244.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="od67eMOl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1774881235; x=1775140435; bh=gDBMQkfHnwQdapFOEWUlLxhTfDL9GpT+jCrwjbzqofU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=od67eMOlQ+NaI/AYiqnm8BOOip9pxmsJUVxLQvmVWpte+3qlXsdTJZ25X9Spt8iZJ qigfk8oZija7lIu+FhdZ3PNt4dZilS47LxLU/777CfjPV5uMeNlGatFZSx5N6kGJ9t KAFvyzG+MURSpLwUsKleMb4jl5g3RrPx1q3tE5xXxUbgTJMXy1C08QtIs0JfAUp+9N f713qUHe9tJoL3nzaPbt1kKPH4VcG83D4gLIgY5066Kpa7tH/p1Ra4T97XZvsC7DUT zLF/YfQPaW+G25OJoJc9Govr3YcO1ewp00Qvka6aNfLQDkcvCTx2vdP7lfo9TLZBSr exhlNxhFJ6y8w== Date: Mon, 30 Mar 2026 14:33:50 +0000 To: Andrew Morton , Mike Rapoport , Uladzislau Rezki From: Maciej Wieczor-Retman Cc: m.wieczorretman@pm.me, Maciej Wieczor-Retman , Alexander Potapenko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v12 07/15] mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic Message-ID: <4a07f48214b0cf5e5888d826183e76af55ffed77.1774872838.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 53838e2a6e7b5d98ce1845d28d58094b9833961a Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman ARCH_HAS_EXECMEM_ROX was re-enabled in x86 at Linux 6.14 release. vm_reset_perms() calculates range's start and end addresses using min() and max() functions. To do that it compares pointers but, with KASAN software tags mode enabled, some are tagged - addr variable is, while start and end variables aren't. This can cause the wrong address to be chosen and result in various errors in different places. Reset tags in the address used as function argument in min(), max(). 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_vmalloc() which then gets propagated to execmem_cache_add(). Signed-off-by: Maciej Wieczor-Retman Acked-by: Alexander Potapenko Acked-by: Mike Rapoport (Microsoft) --- Changelog v10: - Add Mike's acked-by tag. Changelog v7: - Add Alexander's acked-by tag. - Add comments on why these tag resets are needed (Alexander) Changelog v6: - Move back the tag reset from execmem_cache_add() to execmem_vmalloc() (Mike Rapoport) - Rewrite the changelogs to match the code changes from v6 and v5. Changelog v5: - Remove the within_range() change. - arch_kasan_reset_tag -> kasan_reset_tag. Changelog v4: - Add patch to the series. mm/execmem.c | 9 ++++++++- mm/vmalloc.c | 7 ++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/mm/execmem.c b/mm/execmem.c index 084a207e4278..047079efe379 100644 --- a/mm/execmem.c +++ b/mm/execmem.c @@ -59,7 +59,14 @@ static void *execmem_vmalloc(struct execmem_range *range= , size_t size, return NULL; } =20 - return p; + /* + * Resetting the tag here is necessary to avoid the tagged address + * ending up in the maple tree structure. There it's linear address + * can be incorrectly compared with other addresses which can result in + * a wrong address being picked down the line and for example a page + * permission violation error panicking the kernel. + */ + return kasan_reset_tag(p); } =20 struct vm_struct *execmem_vmap(size_t size) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index b31b208f6ecb..b2adc1524bd1 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3361,7 +3361,12 @@ static void vm_reset_perms(struct vm_struct *area) * the vm_unmap_aliases() flush includes the direct map. */ for (i =3D 0; i < area->nr_pages; i +=3D 1U << page_order) { - unsigned long addr =3D (unsigned long)page_address(area->pages[i]); + /* + * Addresses' tag needs resetting so it can be properly used in + * the min() and max() below. Otherwise the start or end values + * might be favoured. + */ + unsigned long addr =3D (unsigned long)kasan_reset_tag(page_address(area-= >pages[i])); =20 if (addr) { unsigned long page_size; --=20 2.53.0