[PATCH v5 18/19] mm: Unpoison vms[area] addresses with a common tag

Maciej Wieczor-Retman posted 19 patches 1 month, 1 week ago
[PATCH v5 18/19] mm: Unpoison vms[area] addresses with a common tag
Posted by Maciej Wieczor-Retman 1 month, 1 week ago
The problem presented here is related to NUMA systems and tag-based
KASAN mode. It can be explained in the following points:

	1. There can be more than one virtual memory chunk.
	2. Chunk's base address has a tag.
	3. The base address points at the first chunk and thus inherits
	   the tag of the first chunk.
	4. The subsequent chunks will be accessed with the tag from the
	   first chunk.
	5. Thus, the subsequent chunks need to have their tag set to
	   match that of the first chunk.

Unpoison all vms[]->addr memory and pointers with the same tag to
resolve the mismatch.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v4:
- Move tagging the vms[]->addr to this new patch and leave refactoring
  there.
- Comment the fix to provide some context.

 mm/kasan/shadow.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index b41f74d68916..ee2488371784 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -646,13 +646,21 @@ void __kasan_poison_vmalloc(const void *start, unsigned long size)
 	kasan_poison(start, size, KASAN_VMALLOC_INVALID, false);
 }
 
+/*
+ * A tag mismatch happens when calculating per-cpu chunk addresses, because
+ * they all inherit the tag from vms[0]->addr, even when nr_vms is bigger
+ * than 1. This is a problem because all the vms[]->addr come from separate
+ * allocations and have different tags so while the calculated address is
+ * correct the tag isn't.
+ */
 void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms)
 {
 	int area;
 
 	for (area = 0 ; area < nr_vms ; area++) {
 		kasan_poison(vms[area]->addr, vms[area]->size,
-			     arch_kasan_get_tag(vms[area]->addr), false);
+			     arch_kasan_get_tag(vms[0]->addr), false);
+		arch_kasan_set_tag(vms[area]->addr, arch_kasan_get_tag(vms[0]->addr));
 	}
 }
 
-- 
2.50.1
Re: [PATCH v5 18/19] mm: Unpoison vms[area] addresses with a common tag
Posted by Andrey Konovalov 3 weeks, 6 days ago
On Mon, Aug 25, 2025 at 10:31 PM Maciej Wieczor-Retman
<maciej.wieczor-retman@intel.com> wrote:
>
> The problem presented here is related to NUMA systems and tag-based
> KASAN mode. It can be explained in the following points:
>
>         1. There can be more than one virtual memory chunk.
>         2. Chunk's base address has a tag.
>         3. The base address points at the first chunk and thus inherits
>            the tag of the first chunk.
>         4. The subsequent chunks will be accessed with the tag from the
>            first chunk.
>         5. Thus, the subsequent chunks need to have their tag set to
>            match that of the first chunk.
>
> Unpoison all vms[]->addr memory and pointers with the same tag to
> resolve the mismatch.
>
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> ---
> Changelog v4:
> - Move tagging the vms[]->addr to this new patch and leave refactoring
>   there.
> - Comment the fix to provide some context.
>
>  mm/kasan/shadow.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index b41f74d68916..ee2488371784 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -646,13 +646,21 @@ void __kasan_poison_vmalloc(const void *start, unsigned long size)
>         kasan_poison(start, size, KASAN_VMALLOC_INVALID, false);
>  }
>
> +/*
> + * A tag mismatch happens when calculating per-cpu chunk addresses, because
> + * they all inherit the tag from vms[0]->addr, even when nr_vms is bigger
> + * than 1. This is a problem because all the vms[]->addr come from separate
> + * allocations and have different tags so while the calculated address is
> + * correct the tag isn't.
> + */
>  void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms)
>  {
>         int area;
>
>         for (area = 0 ; area < nr_vms ; area++) {
>                 kasan_poison(vms[area]->addr, vms[area]->size,
> -                            arch_kasan_get_tag(vms[area]->addr), false);
> +                            arch_kasan_get_tag(vms[0]->addr), false);
> +               arch_kasan_set_tag(vms[area]->addr, arch_kasan_get_tag(vms[0]->addr));
>         }
>  }
>
> --
> 2.50.1
>

Do we need this fix for the HW_TAGS mode too?
Re: [PATCH v5 18/19] mm: Unpoison vms[area] addresses with a common tag
Posted by Maciej Wieczor-Retman 3 weeks, 4 days ago
On 2025-09-06 at 19:19:11 +0200, Andrey Konovalov wrote:
>On Mon, Aug 25, 2025 at 10:31 PM Maciej Wieczor-Retman
><maciej.wieczor-retman@intel.com> wrote:
>>
>> The problem presented here is related to NUMA systems and tag-based
>> KASAN mode. It can be explained in the following points:
>>
>>         1. There can be more than one virtual memory chunk.
>>         2. Chunk's base address has a tag.
>>         3. The base address points at the first chunk and thus inherits
>>            the tag of the first chunk.
>>         4. The subsequent chunks will be accessed with the tag from the
>>            first chunk.
>>         5. Thus, the subsequent chunks need to have their tag set to
>>            match that of the first chunk.
>>
>> Unpoison all vms[]->addr memory and pointers with the same tag to
>> resolve the mismatch.
>>
>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> ---
>> Changelog v4:
>> - Move tagging the vms[]->addr to this new patch and leave refactoring
>>   there.
>> - Comment the fix to provide some context.
>>
>>  mm/kasan/shadow.c | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
>> index b41f74d68916..ee2488371784 100644
>> --- a/mm/kasan/shadow.c
>> +++ b/mm/kasan/shadow.c
>> @@ -646,13 +646,21 @@ void __kasan_poison_vmalloc(const void *start, unsigned long size)
>>         kasan_poison(start, size, KASAN_VMALLOC_INVALID, false);
>>  }
>>
>> +/*
>> + * A tag mismatch happens when calculating per-cpu chunk addresses, because
>> + * they all inherit the tag from vms[0]->addr, even when nr_vms is bigger
>> + * than 1. This is a problem because all the vms[]->addr come from separate
>> + * allocations and have different tags so while the calculated address is
>> + * correct the tag isn't.
>> + */
>>  void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms)
>>  {
>>         int area;
>>
>>         for (area = 0 ; area < nr_vms ; area++) {
>>                 kasan_poison(vms[area]->addr, vms[area]->size,
>> -                            arch_kasan_get_tag(vms[area]->addr), false);
>> +                            arch_kasan_get_tag(vms[0]->addr), false);
>> +               arch_kasan_set_tag(vms[area]->addr, arch_kasan_get_tag(vms[0]->addr));
>>         }
>>  }
>>
>> --
>> 2.50.1
>>
>
>Do we need this fix for the HW_TAGS mode too?

Oh, I suppose it could also affect the hardware mode since this is related to
tagged pointers and NUMA nodes. I'll try to also make it work for HW_TAGS.

-- 
Kind regards
Maciej Wieczór-Retman
Re: [PATCH v5 18/19] mm: Unpoison vms[area] addresses with a common tag
Posted by Andrey Konovalov 3 weeks, 4 days ago
On Mon, Sep 8, 2025 at 3:12 PM Maciej Wieczor-Retman
<maciej.wieczor-retman@intel.com> wrote:
>
> >Do we need this fix for the HW_TAGS mode too?
>
> Oh, I suppose it could also affect the hardware mode since this is related to
> tagged pointers and NUMA nodes. I'll try to also make it work for HW_TAGS.

Ack. I suspect you won't need to provide two separate implementations
for this then.

Also, could you split out this fix into a separate patch with the
Fixes and CC stable tags (or put the fix first in the series)?
Re: [PATCH v5 18/19] mm: Unpoison vms[area] addresses with a common tag
Posted by Maciej Wieczor-Retman 3 weeks, 3 days ago
On 2025-09-08 at 22:19:15 +0200, Andrey Konovalov wrote:
>On Mon, Sep 8, 2025 at 3:12 PM Maciej Wieczor-Retman
><maciej.wieczor-retman@intel.com> wrote:
>>
>> >Do we need this fix for the HW_TAGS mode too?
>>
>> Oh, I suppose it could also affect the hardware mode since this is related to
>> tagged pointers and NUMA nodes. I'll try to also make it work for HW_TAGS.
>
>Ack. I suspect you won't need to provide two separate implementations
>for this then.
>
>Also, could you split out this fix into a separate patch with the
>Fixes and CC stable tags (or put the fix first in the series)?

Sure, I'll move it to the beginning of the series.

-- 
Kind regards
Maciej Wieczór-Retman