CVE-2026-11742
Full vulnerability record from the local CVENow database.
Description
The kernel queue helper z_queue_node_peek() in kernel/queue.c dereferences a node taken from a queue's data_q list, reading the node's flag byte and, for items enqueued via k_queue_alloc_append/alloc_prepend, the data pointer of an internally allocated alloc_node struct. The implementations of z_impl_k_queue_peek_head() and z_impl_k_queue_peek_tail() performed this read-and-dereference without holding the queue's spinlock, while every other accessor of the same list — including k_queue_get(), which unlinks a node and k_free()s its backing alloc_node — operates under that lock. Because peek was unsynchronized, a concurrent k_queue_get() on the same queue (on an SMP build, or under preemption/ISR concurrency) can free the node between the moment peek obtains the node pointer and the moment it dereferences it. The peek then reads flag bits and a data pointer out of freed, potentially re-allocated heap memory and returns a stale or dangling pointer to its caller. k_fifo and k_lifo are thin wrappers over k_queue, so this affects buffer queues used throughout the net_buf, Bluetooth, USB, and networking subsystems; the peek operations are also system calls reachable from CONFIG_USERSPACE threads. The consequences are a use-after-free read that can leak stale heap contents (one pointer word) and, when the returned dangling pointer is subsequently consumed as a live buffer, a dereference that can crash the system or corrupt memory. Exploitation requires winning a small race window with local access (e.g. a userspace process racing k_queue_peek_* against k_queue_get on a shared queue, or two CPUs), so practical impact is bounded and of low severity. The fix wraps both peek implementations with k_spin_lock/k_spin_unlock on the queue lock, making the read-and-dereference atomic with respect to the concurrent unlink-and-free and bringing peek into line with the rest of the queue's locking discipline.
View original CVE JSON
{
"id": "CVE-2026-11742",
"sourceIdentifier": "[email protected]",
"published": "2026-08-07T22:16:57.180",
"lastModified": "2026-10-23T20:10:00.160",
"vulnStatus": "Awaiting Analysis",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "The kernel queue helper z_queue_node_peek() in kernel/queue.c dereferences a node taken from a queue's data_q list, reading the node's flag byte and, for items enqueued via k_queue_alloc_append/alloc_prepend, the data pointer of an internally allocated alloc_node struct. The implementations of z_impl_k_queue_peek_head() and z_impl_k_queue_peek_tail() performed this read-and-dereference without holding the queue's spinlock, while every other accessor of the same list — including k_queue_get(), which unlinks a node and k_free()s its backing alloc_node — operates under that lock.\n\nBecause peek was unsynchronized, a concurrent k_queue_get() on the same queue (on an SMP build, or under preemption/ISR concurrency) can free the node between the moment peek obtains the node pointer and the moment it dereferences it. The peek then reads flag bits and a data pointer out of freed, potentially re-allocated heap memory and returns a stale or dangling pointer to its caller. k_fifo and k_lifo are thin wrappers over k_queue, so this affects buffer queues used throughout the net_buf, Bluetooth, USB, and networking subsystems; the peek operations are also system calls reachable from CONFIG_USERSPACE threads.\n\nThe consequences are a use-after-free read that can leak stale heap contents (one pointer word) and, when the returned dangling pointer is subsequently consumed as a live buffer, a dereference that can crash the system or corrupt memory. Exploitation requires winning a small race window with local access (e.g. a userspace process racing k_queue_peek_* against k_queue_get on a shared queue, or two CPUs), so practical impact is bounded and of low severity.\n\nThe fix wraps both peek implementations with k_spin_lock/k_spin_unlock on the queue lock, making the read-and-dereference atomic with respect to the concurrent unlink-and-free and bringing peek into line with the rest of the queue's locking discipline."
},
{
"lang": "es",
"value": "El asistente de cola del kernel z_queue_node_peek() en kernel/queue.c desreferencia un nodo tomado de la lista data_q de una cola, leyendo el byte de bandera del nodo y, para los elementos encolados a través de k_queue_alloc_append/alloc_prepend, el puntero de datos de una estructura alloc_node asignada internamente. Las implementaciones de z_impl_k_queue_peek_head() y z_impl_k_queue_peek_tail() realizaron esta lectura y desreferencia sin mantener el spinlock de la cola, mientras que cualquier otro accesor de la misma lista - incluyendo k_queue_get(), que desvincula un nodo y libera (k_free()) su alloc_node de respaldo - opera bajo ese bloqueo.\n\nDebido a que peek no estaba sincronizado, un k_queue_get() concurrente en la misma cola (en una compilación SMP, o bajo concurrencia de preemption/ISR) puede liberar el nodo entre el momento en que peek obtiene el puntero del nodo y el momento en que lo desreferencia. El peek luego lee bits de bandera y un puntero de datos de memoria de pila liberada, potencialmente reasignada, y devuelve un puntero obsoleto o colgante a su llamador. k_fifo y k_lifo son envoltorios delgados sobre k_queue, por lo que esto afecta a las colas de búfer utilizadas en los subsistemas net_buf, Bluetooth, USB y de red; las operaciones peek también son llamadas al sistema accesibles desde hilos CONFIG_USERSPACE.\n\nLas consecuencias son una lectura de uso después de liberación que puede filtrar contenido obsoleto de la pila (una palabra de puntero) y, cuando el puntero colgante devuelto se consume posteriormente como un búfer activo, una desreferencia que puede bloquear el sistema o corromper la memoria. La explotación requiere ganar una pequeña ventana de carrera con acceso local (por ejemplo, un proceso de espacio de usuario compitiendo con k_queue_peek_* contra k_queue_get en una cola compartida, o dos CPUs), por lo que el impacto práctico es limitado y de baja severidad.\n\nLa solución envuelve ambas implementaciones de peek con k_spin_lock/k_spin_unlock en el bloqueo de la cola, haciendo que la lectura y desreferencia sea atómica con respecto a la desvinculación y liberación concurrente y alineando peek con el resto de la disciplina de bloqueo de la cola."
}
],
"affected": [
{
"source": "[email protected]",
"affectedData": [
{
"vendor": "zephyrproject",
"product": "zephyr",
"defaultStatus": "unaffected",
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"packageName": "zephyr",
"programFiles": [
"kernel/queue.c"
],
"versions": [
{
"version": "1.12.0",
"lessThan": "4.4.2",
"versionType": "semver",
"status": "affected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "[email protected]",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:L",
"baseScore": 3.6,
"baseSeverity": "LOW",
"attackVector": "LOCAL",
"attackComplexity": "HIGH",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"availabilityImpact": "LOW"
},
"exploitabilityScore": 1.0,
"impactScore": 2.5
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2026-08-10T16:57:12.229945Z",
"id": "CVE-2026-11742",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"version": "2.0.3"
}
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-416"
}
]
}
],
"references": [
{
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/a6b6149a50cb0f64061869f7536acbf80ccc5e0c",
"source": "[email protected]"
},
{
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8xm3-4w69-29mm",
"source": "[email protected]"
}
]
}