CVE-2026-19574: ARM64 MMU can assign an in-use ASID to a new memory domain, breaking user-mode memory isolation

The ARM64 MMU back-end allocated address space identifiers (ASIDs) for memory domains with a bare round-robin counter in archmemdomaininit() (arch/arm64/core/mmu.c). VMASIDBITS is 8, so only 255 ASIDs exist; once the counter wrapped, archmemdomaininit() could hand an ASID to a new domain while a still-live domain held the same one. Domain-private mappings are installed non-global (MTNG), so the ASID is the only tag separating one domain's cached translations from another's in the TLB.

The context-switch path in zarm64swapptables() only flushes the TLB when the outgoing and incoming domains carry the same ASID, which does not cover a duplicate reached through a third domain: for domains A and C sharing an ASID and an unrelated domain B, the schedule A -> B -> C never takes the flush branch, so the ASID-tagged entries A populated remain resident while C runs. Under SMP two live domains sharing an ASID can additionally be resident on two CPUs at once, which the architecture does not allow for distinct translation-table sets.

Triggering the wrap requires a CONFIGUSERSPACE application on ARM64 that creates more than 255 memory domains over its lifetime; kmemdomaininit() and kmemdomaindeinit() are supervisor-only APIs and are not exposed as syscalls, so an unprivileged thread cannot drive the counter directly. Once two live domains alias, however, a user-mode thread in one domain can read and write memory belonging to the other domain's partitions and thread stacks with that domain's permissions, defeating the memory-domain isolation boundary.

The fix scans the live domainlist before assigning an ASID, advances the round-robin counter past ASIDs already in use, and returns -ENOMEM when all are taken, so domain creation fails closed instead of silently aliasing.