Skip to main content
VulnerabilityPublished Updated

CVE-2026-11742: zephyrproject zephyr · Use After Free

Affects zephyrproject zephyrSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 3.6 Low : upgrade to 4.4.2 or 4.3.2 when convenient.

Data as of 5 Nov 2026, 11:40 UTC

CVSS 3.1 base score
3.6Low
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (zephyr)CVSS 3.13.6
EPSS
0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 4.4.2, 4.3.2
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:L

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 7 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.

What to do

Upgrade zephyrproject zephyr to 4.4.2 or 4.3.2.

Affected software

ProductAffectedFixed in
zephyrprojectzephyrAffected
  • >=4.4.0 <4.4.2
Fixed in
  • 4.4.2
zephyrprojectzephyrAffected
  • >=1.12.0 <4.3.2
Fixed in
  • 4.3.2
GitHubzephyrpkg:github/zephyrOther threatsAffected
  • >=1.12.0 <4.3.2
  • >=4.4.0 <4.4.2
Fixed in
  • 4.3.2
  • 4.4.2

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

The described fix involves adding spinlock protection around the peek operations to prevent concurrent free races. If you cannot patch yet, avoid concurrent peek and get operations on the same queue from different threads or CPUs.

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.

References

Community reviews

Loading reviews…