[PATCH] arm64: mte: Do not flag the zero page as PG_mte_tagged
David Hildenbrand
david at redhat.com
Wed Sep 24 05:49:46 PDT 2025
On 24.09.25 14:48, Lance Yang wrote:
>
>
> On 2025/9/24 20:31, Catalin Marinas wrote:
>> Commit 68d54ceeec0e ("arm64: mte: Allow PTRACE_PEEKMTETAGS access to the
>> zero page") attempted to fix ptrace() reading of tags from the zero page
>> by marking it as PG_mte_tagged during cpu_enable_mte(). The same commit
>> also changed the ptrace() tag access permission check to the VM_MTE vma
>> flag while turning the page flag test into a WARN_ON_ONCE().
>>
>> Attempting to set the PG_mte_tagged flag early with
>> CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled may either hang (after commit
>> d77e59a8fccd "arm64: mte: Lock a page for MTE tag initialisation") or
>> have the flags cleared later during page_alloc_init_late(). In addition,
>> pages_identical() -> memcmp_pages() will reject any comparison with the
>> zero page as it is marked as tagged.
>>
>> Partially revert the above commit to avoid setting PG_mte_tagged on the
>> zero page. Update the __access_remote_tags() warning on untagged pages
>> to ignore the zero page since it is known to have the tags initialised.
>>
>> Note that all user mapping of the zero page are marked as pte_special().
>> The arm64 set_pte_at() will not call mte_sync_tags() on such pages, so
>> PG_mte_tagged will remain cleared.
>>
>> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
>> Fixes: 68d54ceeec0e ("arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero page")
>> Reported-by: Gergely Kovacs <Gergely.Kovacs2 at arm.com>
>> Cc: <stable at vger.kernel.org> # 5.10.x
>> Cc: Will Deacon <will at kernel.org>
>> Cc: David Hildenbrand <david at redhat.com>
>> Cc: Lance Yang <lance.yang at linux.dev>
>> ---
>>
>> For reference, discussion on page merging here:
>>
>> https://lore.kernel.org/r/aNKJ5glToE4hMhWA@arm.com
>
> Cool. LGTM.
> Acked-by: Lance Yang <lance.yang at linux.dev>
Likely you can provide even a Tested-by? Just saying :)
--
Cheers
David / dhildenb
More information about the linux-arm-kernel
mailing list