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.
This fix is not being backported to v3.7-branch (LTS). The backport was attempted and closed unmerged (#111181): the v3.7 networking tree has diverged from main, and the new atomic word-packing -- together with the assertions it adds -- turns pre-existing v3.7-only reference-counting defects elsewhere in the stack into hard faults, so landing the change faithfully would mean pulling an open-ended set of additional v3.7-only fixes into an LTS branch. v3.7 remains affected. Applications on v3.7 that share one net_buf across threads should serialize their own net_buf_unref() calls rather than rely on the documented self-synchronizing behaviour. The fix is on main and has been backported to v4.3-branch (#110852) and v4.4-branch (#110853).
What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)
The EG score (8.1): severity, escalated by confirmed exploitation. This CVE's 8.1 is its impact severity (EG Severity), not escalated.
- EG Severity
- 8.1 HIGHCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.NVD CVSS v3 · CVSS v3.0 or v3.1
- EG Likelihood
- 0.4% within 30 daysSource: FIRST EPSS (model v2026.06.15, score date 2026-10-25). FIRST's exploitation probability, not an EchelonGraph model.
- Confirmed exploitation
- None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
- EG Priority
- SSVC Track at medium mission impactTrack at every mission impact level.CISA BOD 26-04: 60 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source: the SSVC and BOD 26-04 blocks below.
SSVC (CISA's decision table, applied by EchelonGraph)Track at every mission impact level.
A fix is referenced, but no release containing it is confirmed. Check the referenced fix and the vendor's advisory for a release that contains it and apply that within your standard update timelines; until then, restrict network exposure of the affected system or apply the vendor's mitigation.
Exploitation none (CISA Vulnrichment) · Automatable no (CISA Vulnrichment) · Technical impact partial (CISA Vulnrichment). All three are CISA's SSVC values (Vulnrichment). EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table
BOD 26-04 (CISA's remediation timeline, Table 1)60 days if the affected system is publicly exposed; Fix on system upgrade if it is not.
In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA Vulnrichment) · Technical impact partial (CISA Vulnrichment). Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it