Zephyr RTOS CVE-2026-19574

Requires a Zephyr ARM64 target built with CONFIG_USERSPACE whose application legitimately calls the supervisor-only k_mem_domain_init() more than 255 times over its lifetime (VM_ASID_BITS=8 gives only 255 ASIDs), wrapping the round-robin counter so two live domains alias the same non-global (MT_NG) ASID. It further requires a scheduling condition where z_arm64_swap_ptables() does not flush - the outgoing and incoming domains do not share the ASID directly (e.g. the A->B->C three-domain sequence), or under SMP the two aliased domains are resident on separate CPUs simultaneously. Strong limiting factors: k_mem_domain_init/deinit are NOT exposed as syscalls, so an unprivileged thread cannot create domains or drive the wrap itself - the application must create that many domains for the aliasing to arise; the attacker thread must already run in user mode inside one of the aliased domains; and non-ARM64 architectures and non-USERSPACE builds are entirely unaffected.

Signals converge on genuinely moderate, not urgent, risk. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N) is the strongest discriminator: exploitation is local (attacker must already run code on the device), high-complexity, and requires low privileges, which caps the base score at 7.0 HIGH despite full C:H/I:H/A:H impact. No EPSS score was provided in the input, so exploitation probability cannot be quantified. KEV status is NO and no POC is referenced, so there is no public exploit identified at time of analysis. No SSVC decision data was supplied. The AC:H rating is well justified: the flaw only manifests after a CONFIG_USERSPACE ARM64 application legitimately creates more than 255 memory domains over its lifetime (wrapping the 8-bit ASID counter) AND two aliased live domains happen to be scheduled such that the z_arm64_swap_ptables() flush branch is bypassed (e.g. the A->B->C schedule, or concurrent residency under SMP). Crucially, the supervisor-only k_mem_domain_init/deinit APIs are not exposed as syscalls, so an unprivileged thread cannot drive the counter to the wrap condition itself - this is a strong limiting factor that argues against opportunistic or widespread exploitation. This is a real isolation-boundary defect worth patching on affected ARM64 userspace deployments, but it is a high-CVSS-impact / low-real-world-likelihood issue for the general Zephyr population rather than a drop-everything priority.

On an ARM64 Zephyr build with CONFIG_USERSPACE, a long-running application creates over 255 memory domains during its lifetime, wrapping the ASID counter so a new domain is handed an ASID still held by a live domain. When the scheduler runs the two aliased domains without triggering the context-switch TLB flush, a user-mode thread in one domain can read and write the other domain's partitions and thread stacks, breaking memory isolation. No public exploit code is identified at time of analysis, and the local, high-complexity vector means an attacker must already execute code on the device.