CVE-2026-10653
MEDIUMThe 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…
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.
Affected Products
zephyrzephyrprojectDetection & mitigation playbook
Vendor / applianceDetect
Inventory every zephyrproject zephyr deployment and check each version against the affected-products list above. Because the exploit targets the running system rather than your application code, also watch for exploitation at the network and runtime layer — O3 flags the exploit behaviour from runtime telemetry and egress traffic even before a vulnerable build is confirmed.
Remediation status
No patch has shipped for CVE-2026-10653 yet — track the zephyrproject zephyr advisory for a fixed release and apply the workarounds below in the meantime.
Mitigate without a patch
Cut exposure now: restrict the management/admin interface to trusted networks, segment the device, and apply the vendor's recommended configuration mitigations and any WAF/IPS signature. O3's runtime protection blocks the exploit chain at execution, holding the line on unpatched or end-of-life systems until you can patch.
How O3 protects you
O3 detects and blocks CVE-2026-10653 exploitation at runtime: eBPF exploit-chain detection, plus L7 egress monitoring that catches the post-exploitation callback and severs the attacker's outbound channel.
Tailored to CVE-2026-10653. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-10653 being exploited in your environment?
O3's eBPF runtime sensors and L7 egress monitoring detect and block the CVE-2026-10653 exploit chain at execution — protecting unpatched and end-of-life systems until the vendor patch is applied.