PT-2026-58038 · Zephyrproject · Zephyr
Publicado
2026-07-14
·
Atualizado
2026-07-14
·
CVE-2026-10671
CVSS v3.1
7.1
Alta
| Vetor | AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H |
In Zephyr's kernel pipe implementation, the userspace syscall verifier z vrfy k pipe init() in kernel/pipe.c used K SYSCALL OBJ() (which requires the kernel object to already be initialized) instead of K SYSCALL OBJ NEVER INIT() (which rejects an already-initialized object). As a result, on CONFIG USERSPACE builds an unprivileged user thread that has been granted access to a k pipe object can invoke the k pipe init syscall to re-initialize a pipe that is already in use.
z impl k pipe init() unconditionally resets the ring buffer, sets pipe->waiting to 0, and re-initializes both wait queues (z waitq init on pipe->data and pipe->space) without waking or accounting for threads currently blocked on the pipe. Any thread already pended in k pipe read()/k pipe write() is left orphaned: still marked pending with pended on pointing at the cleared wait queue and with stale qnode dlist links into the (now re-initialized) embedded list head.
When such an orphaned waiter is later timed out or woken, the scheduler calls sys dlist remove() 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 K SYSCALL OBJ NEVER INIT(), matching the existing k msgq init 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.
Correção
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Enumeração de Fraquezas
Identificadores relacionados
Produtos afetados
Zephyr