CVE-2026-10671: User thread can re-initialize an in-use `k_pipe`, corrupting kernel wait queues (`CONFIG_USERSPACE`)

In Zephyr's kernel pipe implementation, the userspace syscall verifier zvrfykpipeinit() in kernel/pipe.c used KSYSCALLOBJ() (which requires the kernel object to already be initialized) instead of KSYSCALLOBJNEVERINIT() (which rejects an already-initialized object). As a result, on CONFIGUSERSPACE builds an unprivileged user thread that has been granted access to a kpipe object can invoke the kpipeinit syscall to re-initialize a pipe that is already in use.

zimplkpipeinit() unconditionally resets the ring buffer, sets pipe->waiting to 0, and re-initializes both wait queues (zwaitqinit on pipe->data and pipe->space) without waking or accounting for threads currently blocked on the pipe. Any thread already pended in kpiperead()/kpipewrite() is left orphaned: still marked pending with pendedon pointing at the cleared wait queue and with stale qnodedlist links into the (now re-initialized) embedded list head.

When such an orphaned waiter is later timed out or woken, the scheduler calls sysdlistremove() on its stale node, writing through dangling prev/next pointers into kernel wait-queue/scheduler structures, causing list corruption (an attacker-driven invalid kernel write), lost wakeups, indefinitely blocked threads, and silent data loss. The flaw lets a deprivileged user thread corrupt the state of a kernel object shared with other threads/partitions.

The fix switches the verifier to KSYSCALLOBJNEVERINIT(), matching the existing kmsgqinit verifier, so a user thread can no longer re-initialize a live pipe. The vulnerable code shipped in v4.1.0 and remained through v4.4.0.