CVE-2026-11742
Received Received - Intake

Use-After-Free in Zephyr RTOS Kernel Queue

Vulnerability report for CVE-2026-11742, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-08-07

Last updated on: 2026-08-07

Assigner: Zephyr Project

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-07
Last Modified
2026-08-07
Generated
2026-08-08
AI Q&A
2026-08-08
EPSS Evaluated
N/A
NVD

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
zephyrproject zephyr From 2.0.0 (inc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This is a use-after-free vulnerability in the Zephyr RTOS kernel queue helper function z_queue_node_peek(). It occurs because peek operations read and dereference a node pointer without holding the queue's spinlock, while other operations like k_queue_get() free nodes under that lock. This allows a race condition where a node is freed between peek obtaining the pointer and dereferencing it, leading to reading freed memory.

Detection Guidance

This vulnerability involves a race condition in the Zephyr RTOS kernel queue operations. Detection requires analyzing kernel code for unsynchronized calls to z_queue_node_peek(), z_impl_k_queue_peek_head(), or z_impl_k_queue_peek_tail(). Check if your system uses k_queue, k_fifo, or k_lifo APIs without proper spinlock protection during peek operations.

Impact Analysis

The vulnerability can cause memory corruption or system crashes when a dangling pointer returned by peek is later used. It may also leak stale heap contents. Exploitation requires local access and winning a small race window, so practical impact is limited but possible on SMP systems or with preemption.

Compliance Impact

This vulnerability involves a use-after-free read in kernel queue operations, which could lead to memory corruption or crashes. While it requires local access and a race condition, it may impact data integrity and system stability. Compliance with GDPR or HIPAA typically depends on maintaining data integrity and system availability, but this issue's low severity and bounded impact suggest minimal direct regulatory impact.

Mitigation Strategies

Apply the official patch from Zephyr Project that wraps peek operations with k_spin_lock/k_spin_unlock. Update to a version where z_impl_k_queue_peek_head() and z_impl_k_queue_peek_tail() use proper locking. Alternatively, avoid using queue peek operations in multi-threaded contexts until patched.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-11742. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart