CVE-2026-78118: Race condition on kernel wait queues: unlocked z_waitq_head() read in the timer expiration handler can yield a stale or sentinel thread pointer on SMP

The kernel helper zwaitqhead() (kernel/include/waitq.h) reads the head of a thread wait queue, but on SMP systems it was called from several places without holding the scheduler spinlock schedspinlock that serializes wait-queue mutation. The consequential call site is ztimerexpirationhandler() in kernel/timer.c, which held only the timer subsystem lock timerlock while reading timer->waitq and then unpending, setting the return value of, and readying the thread it obtained. haltthread() in kernel/sched.c removes an aborted thread from its wait queue while holding only schedspinlock, so the two paths are not mutually exclusive.

When the last waiter is removed on another CPU inside that window, sysdlistpeekhead() can return the list sentinel — a pointer into the ktimer object itself — typed as a struct kthread (with CONFIGWAITQSCALABLE, rbgetmin() can return an arbitrary node of a tree being restructured), or it can return a pointer to a thread that has already been unpended and, for dynamically allocated threads, freed. The handler then calls unpendthreadnotimeout(), which performs a sysdlistremove() through pointers read from that object, and archthreadreturnvalueset(), which writes unconditionally through the pointer.

The result is out-of-bounds and use-after-free writes in supervisor context, plus scheduler state corruption; a milder outcome is a thread that has re-pended elsewhere being woken with a success return value from an unrelated blocking call. All of the primitives needed to drive the interleaving — ktimerstart(), ktimerstatussync(), kthreadcreate() and kthreadabort() — are system calls, so with CONFIGUSERSPACE enabled an unprivileged user-mode thread can attempt the race against kernel-owned data.

Exploitation requires a multi-CPU build (CONFIGMPMAXNUMCPUS greater than one; the affected region is a no-op on uniprocessor targets), local code execution, and winning a narrow timing window, so the practical outcome is most often a kernel crash rather than controlled corruption. The fix splits the helper into zwaitqheadlocked() for callers that already hold the scheduler spinlock and a zwaitqhead() that acquires it, and brings the timer expiration handler's head read, unpend and ready under a single LOCKSCHEDSPINLOCK region.