Zephyr’s net_buf library uses non‑atomic operations to modify its two reference counters: the header count (buf->ref) and the per‑data‑block count at the beginning of each allocated buffer. The API is advertised as self‑synchronizing, so multiple threads can share a single buffer and each call net_buf_unref() without external locking. However, under true concurrency—such as SMP or preemption within a single core—the non‑atomic increment/decrement allows two contexts to observe the same pre‑decrement value, each concluding it is the last reference. Consequently, a buffer may be freed twice. When the data block lives in heap or variable pools, this double free corrupts heap metadata and produces a use‑after‑free on the heap‑hardening poison. For the header reference count, the buffer is returned twice to the pool’s LIFO free list, corrupting the list so a later allocation may hand the same buffer to two owners. The fault is triggered purely by a reference‑count/timing race, so an attacker only has a weak indirect influence over the race window.

All Zephyr releases up through version 4.4.0 are affected. The issue is present in the Zephyr project’s network buffer library across all modules that use net_buf, including networking, Bluetooth, zbus, and USBIP.

The CVSS score of 6.4 indicates a moderate severity. The EPSS score of 0.00237 (below 1%) suggests a very low but nonzero probability that the vulnerability is exploited; it is not listed in CISA’s KEV catalog. Exploitation requires true concurrency, such as SMP or preemption between the non‑atomic load and store when another context releases the same buffer. An external attacker has at most indirect influence over the race window, so while the flaw is serious, successful exploitation would depend on a highly orchestrated scenario rather than a simple remote attack.