[PATCH] mm/huge_memory: Initialise the tags of the huge zero folio

[Mark Brown]

On Fri, Oct 31, 2025 at 04:57:50PM +0000, Catalin Marinas wrote:

> On arm64 with MTE enabled, a page mapped as Normal Tagged (PROT_MTE) in
> user space will need to have its allocation tags initialised. This is
> normally done in the arm64 set_pte_at() after checking the memory
> attributes. Such page is also marked with the PG_mte_tagged flag to
> avoid subsequent clearing. Since this relies on having a struct page,
> pte_special() mappings are ignored.

We are seeing breakage in userspace on a range of arm64 platforms which
bisects to this commit in -next.  We see traces like:

[   59.746701] Internal error: Oops - Undefined instruction: 0000000002000000 [#1]  SMP

...

[   59.819007] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   59.826055] pc : mte_zero_clear_page_tags+0x1c/0x40
[   59.830980] lr : tag_clear_highpage+0x68/0x118

...

[   59.911874] Call trace:
[   59.914333]  mte_zero_clear_page_tags+0x1c/0x40 (P)
[   59.919278]  get_page_from_freelist+0x1a60/0x1c80
[   59.924042]  __alloc_frozen_pages_noprof+0x178/0xd20
[   59.929068]  alloc_pages_mpol+0xb4/0x1a4
[   59.933022]  alloc_frozen_pages_noprof+0x48/0xc0
[   59.937683]  folio_alloc_noprof+0x14/0x68
[   59.941718]  mm_get_huge_zero_folio+0xf4/0x30c
[   59.946200]  do_huge_pmd_anonymous_page+0x278/0x6a0
[   59.951119]  __handle_mm_fault+0x700/0x1834
[   59.955332]  handle_mm_fault+0x8c/0x2a0
[   59.959190]  do_page_fault+0x108/0x75c
[   59.962964]  do_translation_fault+0x5c/0x6c
[   59.967181]  do_mem_abort+0x40/0x90

Looking at the codes:

> -       zero_folio = folio_alloc((GFP_TRANSHUGE | __GFP_ZERO) & ~__GFP_MOVABLE,
> +       zero_folio = folio_alloc((GFP_TRANSHUGE | __GFP_ZERO | __GFP_ZEROTAGS) &
> +                                ~__GFP_MOVABLE,
>                         HPAGE_PMD_ORDER);

This adds an unonditional __GFP_ZEROTAGS - from a quick scan it looks
like this was previously only enabled by vma_alloc_zeroed_movable_folio()
when the VMA has VM_MTE, I think we need a similar test here.

Full log:

   https://lava.sirena.org.uk/scheduler/job/2036941#L1423

Sample bisect log (with links to further runtime logs:

# bad: [3575af345aa2424636e69ac101a568bda249abe6] Merge branch 'i2c/i2c-host-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
# good: [6146a0f1dfae5d37442a9ddcba012add260bceb0] Linux 6.18-rc4
git bisect start '3575af345aa2424636e69ac101a568bda249abe6' '6146a0f1dfae5d37442a9ddcba012add260bceb0'
# test job: [3575af345aa2424636e69ac101a568bda249abe6] https://lava.sirena.org.uk/scheduler/job/2036941
# bad: [3575af345aa2424636e69ac101a568bda249abe6] Merge branch 'i2c/i2c-host-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
git bisect bad 3575af345aa2424636e69ac101a568bda249abe6
# test job: [81f07f151b0759666fee3184651aab90ef1c5ed5] https://lava.sirena.org.uk/scheduler/job/2037418
# bad: [81f07f151b0759666fee3184651aab90ef1c5ed5] Merge branch 'usb-linus' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
git bisect bad 81f07f151b0759666fee3184651aab90ef1c5ed5
# test job: [661821dc41b20c505d5adad10bb71fe5746c57fb] https://lava.sirena.org.uk/scheduler/job/2037588
# bad: [661821dc41b20c505d5adad10bb71fe5746c57fb] Merge branch 'fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl.git
git bisect bad 661821dc41b20c505d5adad10bb71fe5746c57fb
# test job: [972cbfc499182c200bd3d2fb8fe4173df0d4d3e7] https://lava.sirena.org.uk/scheduler/job/2037773
# bad: [972cbfc499182c200bd3d2fb8fe4173df0d4d3e7] mm/huge_memory: initialise the tags of the huge zero folio
git bisect bad 972cbfc499182c200bd3d2fb8fe4173df0d4d3e7
# test job: [6923ff319e1b0d3541cd240b6ed494e1cb6287d1] https://lava.sirena.org.uk/scheduler/job/2037885
# good: [6923ff319e1b0d3541cd240b6ed494e1cb6287d1] fs/proc: fix uaf in proc_readdir_de()
git bisect good 6923ff319e1b0d3541cd240b6ed494e1cb6287d1
# test job: [e356021a7589f6dd1c946b86c933462dca0bc1ec] https://lava.sirena.org.uk/scheduler/job/2037973
# good: [e356021a7589f6dd1c946b86c933462dca0bc1ec] codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
git bisect good e356021a7589f6dd1c946b86c933462dca0bc1ec
# test job: [decb83d6239894a14b07c8f5ebf9feb5c87ec651] https://lava.sirena.org.uk/scheduler/job/2038008
# good: [decb83d6239894a14b07c8f5ebf9feb5c87ec651] mm/damon/sysfs: change next_update_jiffies to a global variable
git bisect good decb83d6239894a14b07c8f5ebf9feb5c87ec651
# test job: [53cf2716958490997b8ce11cc4665256905b23dd] https://lava.sirena.org.uk/scheduler/job/2038076
# good: [53cf2716958490997b8ce11cc4665256905b23dd] nilfs2: avoid having an active sc_timer before freeing sci
git bisect good 53cf2716958490997b8ce11cc4665256905b23dd
# first bad commit: [972cbfc499182c200bd3d2fb8fe4173df0d4d3e7] mm/huge_memory: initialise the tags of the huge zero folio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20251103/5fff0242/attachment.sig>