CVE-2026-10653: use-after-free in zephyrproject zephyr
The Zephyr net_buf library (lib/net_buf/buf.c) manipulated both of its reference counts -- the per-header buf->ref and the per-data-block ref_count at the start of each variable/heap data allocation -- with plain non-atomic C operators (buf->ref++, if (--buf->ref > 0), if (--(*ref_count))). The API is documented as self-synchronizing: callers may share one buffer across threads (e.g. via k_fifo) and each holder independently calls net_buf_unref() with no surrounding lock. Under true concurrency (SMP, or single-core preemption between the non-atomic load and store while another context unrefs the same buffer), two holders can both observe the same prior reference value and both conclude they are the last reference. For heap/variable-data pools (mem_pool_data_unref/heap_data_unref, used by zbus message subscribers, the IP stack RX/TX buffers when CONFIG_NET_BUF_FIXED_DATA_SIZE=n, capture, wireguard, ISO-TP and usbip) this produces a double k_heap_free()/k_free() of the same block -- heap-metadata corruption and a use-after-free on the heap-hardening poison pattern. For the per-header refcount the buffer is returned to the pool free LIFO twice for any pool type (including fixed-data pools used by Bluetooth and networking), corrupting the free list so a later allocation hands the same buffer to two owners. The fix converts both refcounts to atomic_inc/atomic_dec (overlaying buf->ref in an atomic_t-sized union and changing the data-block refcount from uint8_t to atomic_t). Impact is gated on genuine concurrency and on an application architecture that shares one buffer among multiple independent unref'ers; the trigger is a refcount/timing race rather than packet content, so an external attacker has at most weak indirect influence over the race window. Affects all Zephyr releases through v4.4.0.
AI Analysis
Technical Summary
The Zephyr net_buf library manipulates two reference counts (per-header buf->ref and per-data-block ref_count) using non-atomic C operators. The API is designed to be self-synchronizing, allowing buffers to be shared across threads without locks. However, under true concurrency (SMP or preemption), simultaneous unref operations can cause both holders to believe they are the last reference, leading to double free of heap blocks or double return of buffers to the pool free list. This results in heap metadata corruption and use-after-free conditions. The vulnerability affects heap/variable-data pools used by various subsystems including zbus, IP stack RX/TX buffers, capture, wireguard, ISO-TP, and usbip. The fix involves converting both reference counts to atomic operations. The issue affects all Zephyr versions up to 4.4.0 and requires concurrency and specific buffer sharing patterns to trigger. External attackers have limited indirect influence over the race window.
Potential Impact
The vulnerability can cause heap metadata corruption and use-after-free conditions due to double freeing of memory blocks or double returning buffers to the free pool. This can lead to memory corruption, potentially destabilizing the system or causing crashes. The impact is limited to environments with genuine concurrency and applications that share buffers among multiple independent unref holders. Confidentiality and integrity impacts are rated low, but availability impact is high due to possible crashes or memory corruption.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vendor has described a fix involving conversion of reference counts to atomic operations, but no official patch or advisory link is provided in this data. Until a patch is available, avoid architectures that share buffers across threads without synchronization or disable SMP/preemption features that enable concurrency in affected environments.
CVE-2026-10653: use-after-free in zephyrproject zephyr
Description
The Zephyr net_buf library (lib/net_buf/buf.c) manipulated both of its reference counts -- the per-header buf->ref and the per-data-block ref_count at the start of each variable/heap data allocation -- with plain non-atomic C operators (buf->ref++, if (--buf->ref > 0), if (--(*ref_count))). The API is documented as self-synchronizing: callers may share one buffer across threads (e.g. via k_fifo) and each holder independently calls net_buf_unref() with no surrounding lock. Under true concurrency (SMP, or single-core preemption between the non-atomic load and store while another context unrefs the same buffer), two holders can both observe the same prior reference value and both conclude they are the last reference. For heap/variable-data pools (mem_pool_data_unref/heap_data_unref, used by zbus message subscribers, the IP stack RX/TX buffers when CONFIG_NET_BUF_FIXED_DATA_SIZE=n, capture, wireguard, ISO-TP and usbip) this produces a double k_heap_free()/k_free() of the same block -- heap-metadata corruption and a use-after-free on the heap-hardening poison pattern. For the per-header refcount the buffer is returned to the pool free LIFO twice for any pool type (including fixed-data pools used by Bluetooth and networking), corrupting the free list so a later allocation hands the same buffer to two owners. The fix converts both refcounts to atomic_inc/atomic_dec (overlaying buf->ref in an atomic_t-sized union and changing the data-block refcount from uint8_t to atomic_t). Impact is gated on genuine concurrency and on an application architecture that shares one buffer among multiple independent unref'ers; the trigger is a refcount/timing race rather than packet content, so an external attacker has at most weak indirect influence over the race window. Affects all Zephyr releases through v4.4.0.
CVSS v3.1
Score 6.4medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Zephyr net_buf library manipulates two reference counts (per-header buf->ref and per-data-block ref_count) using non-atomic C operators. The API is designed to be self-synchronizing, allowing buffers to be shared across threads without locks. However, under true concurrency (SMP or preemption), simultaneous unref operations can cause both holders to believe they are the last reference, leading to double free of heap blocks or double return of buffers to the pool free list. This results in heap metadata corruption and use-after-free conditions. The vulnerability affects heap/variable-data pools used by various subsystems including zbus, IP stack RX/TX buffers, capture, wireguard, ISO-TP, and usbip. The fix involves converting both reference counts to atomic operations. The issue affects all Zephyr versions up to 4.4.0 and requires concurrency and specific buffer sharing patterns to trigger. External attackers have limited indirect influence over the race window.
Potential Impact
The vulnerability can cause heap metadata corruption and use-after-free conditions due to double freeing of memory blocks or double returning buffers to the free pool. This can lead to memory corruption, potentially destabilizing the system or causing crashes. The impact is limited to environments with genuine concurrency and applications that share buffers among multiple independent unref holders. Confidentiality and integrity impacts are rated low, but availability impact is high due to possible crashes or memory corruption.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vendor has described a fix involving conversion of reference counts to atomic operations, but no official patch or advisory link is provided in this data. Until a patch is available, avoid architectures that share buffers across threads without synchronization or disable SMP/preemption features that enable concurrency in affected environments.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- zephyr
- Date Reserved
- 2026-06-02T15:24:26.926Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a43f42f27e9c79719185ebf
Added to database: 06/30/2026, 16:51:59 UTC
Last enriched: 06/30/2026, 17:08:25 UTC
Last updated: 06/30/2026, 23:25:00 UTC
Views: 5
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.