linux-kernel - Re: [PATCH v6 09/18] mm/execmem: Untag addresses in EXECMEM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5ty6jsrleekmymktmyayidc5jdvqvzz622vsh4fqk3rjtgyalu@argn7tfm3efv>
Date: Mon, 17 Nov 2025 18:43:09 +0000
From: Maciej Wieczór-Retman <m.wieczorretman@...me>
To: Alexander Potapenko <glider@...gle.com>
Cc: xin@...or.com, peterz@...radead.org, kaleshsingh@...gle.com, kbingham@...nel.org, akpm@...ux-foundation.org, nathan@...nel.org, ryabinin.a.a@...il.com, dave.hansen@...ux.intel.com, bp@...en8.de, morbo@...gle.com, jeremy.linton@....com, smostafa@...gle.com, kees@...nel.org, baohua@...nel.org, vbabka@...e.cz, justinstitt@...gle.com, wangkefeng.wang@...wei.com, leitao@...ian.org, jan.kiszka@...mens.com, fujita.tomonori@...il.com, hpa@...or.com, urezki@...il.com, ubizjak@...il.com, ada.coupriediaz@....com, nick.desaulniers+lkml@...il.com, ojeda@...nel.org, brgerst@...il.com, elver@...gle.com, pankaj.gupta@....com, mark.rutland@....com, trintaeoitogc@...il.com, jpoimboe@...nel.org, thuth@...hat.com, pasha.tatashin@...een.com, dvyukov@...gle.com, jhubbard@...dia.com, catalin.marinas@....com, yeoreum.yun@....com, mhocko@...e.com, lorenzo.stoakes@...cle.com, samuel.holland@...ive.com, vincenzo.frascino@....com, bigeasy@...utronix.de, surenb@...gle.com, ardb@...nel.org,
	Liam.Howlett@...cle.com, nicolas.schier@...ux.dev, ziy@...dia.com, kas@...nel.org, tglx@...utronix.de, mingo@...hat.com, broonie@...nel.org, corbet@....net, andreyknvl@...il.com, maciej.wieczor-retman@...el.com, david@...hat.com, maz@...nel.org, rppt@...nel.org, will@...nel.org, luto@...nel.org, kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, x86@...nel.org, linux-kbuild@...r.kernel.org, linux-mm@...ck.org, llvm@...ts.linux.dev, linux-doc@...r.kernel.org
Subject: Re: [PATCH v6 09/18] mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic

On 2025-11-11 at 10:13:57 +0100, Alexander Potapenko wrote:
>On Wed, Oct 29, 2025 at 8:08 PM Maciej Wieczor-Retman
><m.wieczorretman@...me> wrote:
>>
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
>>
>> 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 <maciej.wieczor-retman@...el.com>
>Acked-by: Alexander Potapenko <glider@...gle.com>
>
>> diff --git a/mm/execmem.c b/mm/execmem.c
>> index 810a4ba9c924..fd11409a6217 100644
>> --- a/mm/execmem.c
>> +++ b/mm/execmem.c
>> @@ -59,7 +59,7 @@ static void *execmem_vmalloc(struct execmem_range *range, size_t size,
>>                 return NULL;
>>         }
>>
>> -       return p;
>> +       return kasan_reset_tag(p);
>
>I think a comment would be nice here.
>
>
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -3328,7 +3328,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]));
>
>Ditto

Thanks, will add some comments on why these are needed.