CVE WatchOct 16, 2026

CVE-2026-19738

The Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation retains an RX node (ctx->no

CVSS

6.5

Medium

EPSS

0.1%

KEV

—

Exploit Today

0-100

Published: Oct 11, 2026 · Last modified: Oct 16, 2026 · CWE-401

EPSS · 30d

0.1%EPSS · 30 days0.1%

2026-10-122026-10-21

Technical description

The Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation retains an RX node (ctx->node_ref.rx, marked NODE_RX_TYPE_RETAIN) so it can later be reused as the host notification — on the peripheral while awaiting the Host's reply to an LL_CIS_REQ, and on the central for the whole duration of a locally initiated CIS Create. In subsys/bluetooth/controller/ll_sw/ull_llcp_cc.c, the "invalid PDU received" paths of llcp_rp_cc_rx() and llcp_lp_cc_rx() terminated the connection and completed the procedure without releasing that retained node, breaking the invariant checked in llcp_lr_check_done() and llcp_rr_check_done() and orphaning the node's memory. A peer device within radio range can reach this with a single extra LL Control PDU on an unauthenticated, unencrypted ACL link. Against a peripheral, the attacker sends a valid LL_CIS_REQ and then, before the Host replies, any unrelated LL Control PDU (for example LL_VERSION_IND), which ull_cp_rx() routes into the active remote procedure. Against a central performing a CIS Create, a malicious peripheral answers with LL_UNKNOWN_RSP for CIS_REQ, which is dispatched into the active local procedure. No pairing, encryption or user interaction is required; the code is compiled in when CONFIG_BT_CTLR_PERIPHERAL_ISO or CONFIG_BT_CTLR_CENTRAL_ISO is enabled. In default builds (CONFIG_BT_CTLR_ASSERT_DEBUG is default y) the retained-node assertion fires immediately, producing a controller fatal error and, typically, a system reset from one injected PDU. With the development assertions disabled, each attempt permanently loses one node from the controller's small LL notification pool (LL_PDU_RX_CNT, 2 * CONFIG_BT_CTLR_LLCP_CONN) together with its memq_link_t; repeating the connect-attack-reconnect cycle exhausts the pool, after which notification allocation always fails, RX flow control stalls, and the non-disableable LL_ASSERT_ERR() in llcp_lp_cc_flush() faults. The impact is limited to availability — the leaked node is orphaned, never reused or double-freed — and recovery requires a reboot.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-764895.8 MED

—

———Multiple Cisco products are affected by a vulnerability in the memory management implementation of Snort 3 that could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to restart, resulting in an interruption of packet inspection. This vulnerability is due to incomplete error checking when Snort 3 processes files, which could cause unreleased memory. An attacker could exploit this vulnerability by sending a large number of files to be processed. A successful exploit could allow the attacker to cause the Snort 3 Detection Engine to restart unexpectedly, resulting in a DoS condition.17h CVE-2026-776845.7 MED

9.9%

——3The Bluetooth Classic Hands-Free Profile HF role in subsys/bluetooth/host/classic/hfp_hf.c does not release the AT command buffers that are still queued on hf->tx_pending when the RFCOMM DLC goes down. hfp_hf_disconnected() only cancelled the work items and cleared hf->acl, and no other code path ever dequeues those buffers, so each one is permanently lost from the fixed hf_pool (CONFIG_BT_MAX_CONN + 1 buffers, i.e. two in the default configuration). The same function also left BT_HFP_HF_FLAG_CONNECTED set, and hfp_hf_create() wiped the object with memset() as soon as hf->acl was NULL, without checking whether hf->work, hf->slc_work or hf->deferred_work was still pending or running. The remote Audio Gateway peer controls the trigger end to end and needs no application involvement: an unsolicited +BCS: 1 response makes bcs_handle() call bt_hfp_hf_select_codec() and queue an AT+BCS buffer, which cannot be transmitted while BT_HFP_HF_FLAG_RX_ONGOING is set, and an immediately following RFCOMM DISC strands that buffer. Repeating the connect / +BCS / disconnect cycle a couple of times empties hf_pool for good. With the pool exhausted, HFP command sending fails permanently, and because hfp_hf_send_cmd() allocates with K_FOREVER (bt_rfcomm_create_pdu() → bt_conn_create_pdu()) from the Bluetooth RX context — where that timeout is not downgraded to K_NO_WAIT — one further +BCS from the peer parks the Bluetooth RX thread inside net_buf_alloc() with no possible waker, halting all HCI event processing until the device is rebooted. Separately, reusing the HF slot while a work handler was still queued or running allowed memset() to wipe live k_work items out from under the system workqueue, corrupting shared kernel workqueue state. Exploitation requires an established HFP session (for SSP devices L2CAP enforces authentication before the RFCOMM channel is reachable) and a build with CONFIG_BT_HFP_HF enabled.2d CVE-2026-110685—

6.2%

——2Cpanel::JSON::XS versions before 4.80 for Perl leak the decoded arguments of a tagged value when its THAW method dies in decode_tag. With allow_tags, a tagged value's class name and argument array are decoded and passed to the class's THAW method. Both are released only after THAW returns, so a THAW that dies leaves the whole decoded argument structure allocated. Each rejected document leaks data of a size the sender chooses, so a process that catches the error and keeps running exhausts its memory.3d CVE-2026-110684—

6.2%

——2Cpanel::JSON::XS versions from 3.0202 before 4.80 for Perl leak memory and retain overloaded objects when encoding values as strings in encode_stringify. encode_stringify writes a value in its string form under allow_stringify, under convert_blessed for objects without TO_JSON, and under allow_bignum. For an array or hash object with a "" overload, and from 4.20 a scalar object, it takes an extra reference that is never released, so the object and everything it references are never freed. From 4.10 it also never frees its copy of the string. Repeatedly encoding data that contains such values grows process memory without bound.3d CVE-2026-110677—

6.2%

——2Cpanel::JSON::XS versions from 4.28 before 4.80 for Perl leak the array collecting duplicate key values under dupkeys_as_arrayref in decode_hv. With dupkeys_as_arrayref, the values of a duplicate object key are collected into a new array. An extra reference is never released, so the array and every value in it outlive the decoded structure. The array also leaks when decoding fails after a duplicate key. Repeatedly decoding untrusted JSON with a duplicate key holding a large value exhausts process memory.3d CVE-2026-110672—

6.2%

——2Cpanel::JSON::XS versions before 4.80 for Perl leak the decoded key of an object rejected for a duplicate key or a missing colon in decode_hv. A quoted key of 24 or more bytes, or one containing a non-ASCII byte or an escape sequence, is decoded into a new scalar. Nothing frees that scalar when the object is rejected for a missing ':' after the key or, from 4.09, for a duplicate key. Duplicate keys are an error unless allow_dupkeys, dupkeys_as_arrayref or relaxed is set. A process that keeps running after a failed decode retains one key per rejected document, with its size chosen by the sender. Repeated requests exhaust process memory.3d