GHSA-334c-qm73-x5mv: Xtensa MMU userspace: uninitialized thread page-table pointer leads to out-of-bounds supervisor-mode writes

The Xtensa MMU userspace port never initialized the per-thread page-table pointer thread->arch.ptables during thread setup, while archmemdomainthreadadd() in arch/xtensa/core/ptables.c uses a non-NULL value of that field as its "this thread is migrating from another memory domain" predicate. For a thread whose struct kthread backing memory is not zeroed, the field holds stale data and the kernel takes the migration branch, passing that stale value to resetregion() as the base of a level-1 page table. The equivalent field on x86 is explicitly cleared in zx86userspacepreparethread() for exactly this reason; the Xtensa port adopted the predicate without the initialization.

The condition is reachable from an unprivileged user-mode thread on a build with CONFIGXTENSAMMU, CONFIGUSERSPACE and dynamically allocated kernel objects. kobjectalloc(KOBJTHREAD) is a system call and allocates the thread object from the caller's resource pool without zeroing it, and the kthreadcreate() verifier accepts such an object while forcing the KUSER option, so the migration branch is taken whenever the recycled heap bytes at that offset are non-zero. Because a user thread can also allocate, fill and free other kernel objects from the same heap, the stale bytes are groomable rather than merely random.

Walking the bogus table in regionmapupdate() performs an unguarded index into l2pagetablescounter[], may copy from and write through the attacker-influenceable level-1 base in dupl2tableifneeded(), and finally writes a page-table entry through a second pointer read out of that memory — once per page of the new thread's stack. The result is out-of-bounds reads and writes executed in supervisor mode, ranging from an immediate kernel panic (observed as Xtensa EXCAUSE 13 on Intel ADSP DSP firmware with user threads) to corruption of kernel memory and escape from the user-mode sandbox.