Re: [PATCH v2 2/3] kasan: skip HW tagging for all kernel thread stacks

[Ryan Roberts <ryan.roberts@arm.com>]

On 17/04/2026 09:31, Catalin Marinas wrote:
> On Thu, Apr 16, 2026 at 11:03:46AM +0200, David Hildenbrand wrote:
>> On 4/10/26 20:36, Catalin Marinas wrote:
>>> On Fri, Apr 10, 2026 at 07:32:23PM +0100, Catalin Marinas wrote:
>>>> What the original approach might help with is use-after-realloc in case
>>>> we had a tagged pointer in a past life of a page and it still works now.
>>>> Oh well, that's I guess for other types of hardening to address like
>>>> delayed reallocation.
>>>
>>> Another thought (for a separate series) - we could try to map the stack
>>> as Untagged (unless stack tagging is enabled; needs compiler
>>> instrumentation) and enable canonical tag checking (newer addition to
>>> MTE). This way, any stray tagged pointer won't work on the stack since
>>> it needs a 0xf tag (canonical).
>>
>> Do you mean mapping it as Untagged in the vmap for CONFIG_VMAP_STACK or
>> also as Untagged in the directmap?
>>
>> The latter brings in the set of problems with direct map fragmentation.
> 
> Just the vmap, there are a lot more problems with the direct map. Not
> sure how much it does in terms of security, maybe marginally. A
> match-all tag (0xf) would still be able to access the canonically tagged
> memory.
> 

I think with the first patch in this series, we are alredy vmapping the stack
memory as untagged, right? vmalloc only calls arch_vmap_pgprot_tagged() if we
are not skipping kasan. So I think we already have this protection? (perhaps we
need to explicitly enable the canonical tag checks?)

Thanks,
Ryan