Search
Find a vulnerability
Search criteria
ⓘ
Use this form to refine search results.
Full-text search supports keyword queries with ranking and filtering.
You can combine vendor, product, and sources to narrow results.
Enable “Apply ordering” to sort by date instead of relevance.
326 vulnerabilities
CVE-2026-75085 (GCVE-0-2026-75085)
Vulnerability from cvelistv5 – Published: 2026-10-14 16:46 – Updated: 2026-10-16 15:31
VLAI
EPSS
VEX
Title
Out-of-bounds read from received-frame length underflow in the STM32WBA IEEE 802.15.4 driver
Summary
The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame->length - IEEE802154_FCS_LENGTH without first checking that the radio-reported length could hold an FCS. pkt_len is a uint8_t, so a reported length of 0 or 1 wrapped to 254 or 255. The only bound on the resulting value was __ASSERT_NO_MSG(pkt_len <= CONFIG_NET_BUF_DATA_SIZE), which compiles to nothing in the default production configuration (CONFIG_ASSERT=n).
The length originates in the ST link-layer receive-done metadata (p_metadata->length, stored by stm32wba_802154_receive_done()), and ultimately in the PHY header of a frame received over the air, so it is influenced by any attacker within radio range of the device. Reaching the underflow requires the vendor link layer to surface a frame shorter than the FCS with no error; the driver performed no validation of its own on that value.
When the underflow occurs, stm32wba_802154_rx_thread() calls net_pkt_write(pkt, rx_frame->psdu, pkt_len) with a length of about 254 bytes against a receive buffer that holds at most one PHY packet (IEEE802154_MAX_PHY_PACKET_SIZE, 127 bytes). This reads roughly 128 bytes past the end of the radio receive buffer and copies that adjacent memory into a network packet that is submitted to the networking stack, giving an out-of-bounds read with a potential disclosure of adjacent RAM plus needless oversized packet allocation in the RX thread.
The fix rejects a frame whose reported length is smaller than IEEE802154_FCS_LENGTH before the subtraction, and replaces the compiled-out assertion with a runtime length check that drops oversized frames — matching the runtime check already present in drivers/ieee802154/ieee802154_nrf5.c.
Severity
4.2 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 15:23 UTC
CWE
- CWE-125 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.3.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-75085",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T15:23:46.554080Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T15:31:45.899Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/ieee802154/ieee802154_stm32wba.c"
],
"programRoutines": [
{
"name": "stm32wba_802154_rx_thread"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame-\u003elength - IEEE802154_FCS_LENGTH without first checking that the radio-reported length could hold an FCS. pkt_len is a uint8_t, so a reported length of 0 or 1 wrapped to 254 or 255. The only bound on the resulting value was __ASSERT_NO_MSG(pkt_len \u003c= CONFIG_NET_BUF_DATA_SIZE), which compiles to nothing in the default production configuration (CONFIG_ASSERT=n).\n\nThe length originates in the ST link-layer receive-done metadata (p_metadata-\u003elength, stored by stm32wba_802154_receive_done()), and ultimately in the PHY header of a frame received over the air, so it is influenced by any attacker within radio range of the device. Reaching the underflow requires the vendor link layer to surface a frame shorter than the FCS with no error; the driver performed no validation of its own on that value.\n\nWhen the underflow occurs, stm32wba_802154_rx_thread() calls net_pkt_write(pkt, rx_frame-\u003epsdu, pkt_len) with a length of about 254 bytes against a receive buffer that holds at most one PHY packet (IEEE802154_MAX_PHY_PACKET_SIZE, 127 bytes). This reads roughly 128 bytes past the end of the radio receive buffer and copies that adjacent memory into a network packet that is submitted to the networking stack, giving an out-of-bounds read with a potential disclosure of adjacent RAM plus needless oversized packet allocation in the RX thread.\n\nThe fix rejects a frame whose reported length is smaller than IEEE802154_FCS_LENGTH before the subtraction, and replaces the compiled-out assertion with a runtime length check that drops oversized frames \u2014 matching the runtime check already present in drivers/ieee802154/ieee802154_nrf5.c."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 4.2,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T16:46:02.993Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/46f8af4f5ee472abc13b0291c44fdfe4ed879aaa"
},
{
"name": "GHSA-w7pm-4r95-c9vr",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-w7pm-4r95-c9vr"
}
],
"title": "Out-of-bounds read from received-frame length underflow in the STM32WBA IEEE 802.15.4 driver",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-75085",
"datePublished": "2026-10-14T16:46:02.993Z",
"dateReserved": "2026-08-17T16:17:49.267Z",
"dateUpdated": "2026-10-16T15:31:45.899Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-75084 (GCVE-0-2026-75084)
Vulnerability from cvelistv5 – Published: 2026-10-14 16:46 – Updated: 2026-10-16 15:31
VLAI
EPSS
VEX
Title
Out-of-bounds write in the TI CC1200 IEEE 802.15.4 driver from an unvalidated radio-supplied packet length
Summary
The CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio's RX FIFO in get_packet_length() and validates it in verify_rxfifo_validity() (drivers/ieee802154/ieee802154_cc1200.c). That validation only enforced a lower bound (pkt_len < 3); its second clause rejects a FIFO that holds more bytes than declared and therefore never bounds large values. Because the driver configures the radio for variable packet length with PKT_LEN = 0xFF, the length byte is an over-the-air value of 0-255 that reached net_pkt_rx_alloc_with_buffer() and the subsequent SPI burst read unclamped.
An unauthenticated attacker within radio range can transmit a frame that presents a length byte above the IEEE 802.15.4 maximum of 127 while the chip's 128-byte RX FIFO has not overflowed, so the driver's RX_FIFO_ERROR pre-check does not fire. Reaching this state depends on RF framing and timing, since the RX thread is driven off the PKT_SYNC_RXTX signal and may sample the FIFO before a packet is complete; no pairing, authentication, or user interaction is required.
With the default CONFIG_NET_BUF_FIXED_DATA_SIZE and CONFIG_NET_BUF_DATA_SIZE=128, an allocation larger than one fragment is satisfied by a chain of fragments, but read_rxfifo_content() performs a single SPI burst of pkt_len bytes into the first fragment's buf->data and then calls net_buf_add() with the same length. A length above 128 therefore writes up to 127 bytes past the end of a fragment in the contiguous rx_bufs pool and leaves a net_buf whose len exceeds its capacity. The overflowing bytes are FIFO-underflow output rather than attacker-chosen data, so the practical impact is network-buffer-pool corruption and crashes rather than a controlled write. Only builds that enable CONFIG_IEEE802154_CC1200 with an attached CC1200 radio are affected.
Severity
6.8 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 15:24 UTC
CWE
- CWE-787 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
1.11.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-75084",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T15:24:20.665016Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T15:31:46.056Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/ieee802154/ieee802154_cc1200.c"
],
"programRoutines": [
{
"name": "cc1200_rx"
},
{
"name": "read_rxfifo_content"
},
{
"name": "verify_rxfifo_validity"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "1.11.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio\u0027s RX FIFO in get_packet_length() and validates it in verify_rxfifo_validity() (drivers/ieee802154/ieee802154_cc1200.c). That validation only enforced a lower bound (pkt_len \u003c 3); its second clause rejects a FIFO that holds more bytes than declared and therefore never bounds large values. Because the driver configures the radio for variable packet length with PKT_LEN = 0xFF, the length byte is an over-the-air value of 0-255 that reached net_pkt_rx_alloc_with_buffer() and the subsequent SPI burst read unclamped.\n\nAn unauthenticated attacker within radio range can transmit a frame that presents a length byte above the IEEE 802.15.4 maximum of 127 while the chip\u0027s 128-byte RX FIFO has not overflowed, so the driver\u0027s RX_FIFO_ERROR pre-check does not fire. Reaching this state depends on RF framing and timing, since the RX thread is driven off the PKT_SYNC_RXTX signal and may sample the FIFO before a packet is complete; no pairing, authentication, or user interaction is required.\n\nWith the default CONFIG_NET_BUF_FIXED_DATA_SIZE and CONFIG_NET_BUF_DATA_SIZE=128, an allocation larger than one fragment is satisfied by a chain of fragments, but read_rxfifo_content() performs a single SPI burst of pkt_len bytes into the first fragment\u0027s buf-\u003edata and then calls net_buf_add() with the same length. A length above 128 therefore writes up to 127 bytes past the end of a fragment in the contiguous rx_bufs pool and leaves a net_buf whose len exceeds its capacity. The overflowing bytes are FIFO-underflow output rather than attacker-chosen data, so the practical impact is network-buffer-pool corruption and crashes rather than a controlled write. Only builds that enable CONFIG_IEEE802154_CC1200 with an attached CC1200 radio are affected."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.8,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T16:46:01.701Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/26a8b8294bf28523c7aa2f15cf728517980ee593"
},
{
"name": "GHSA-pgg5-wwxw-vmj8",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-pgg5-wwxw-vmj8"
}
],
"title": "Out-of-bounds write in the TI CC1200 IEEE 802.15.4 driver from an unvalidated radio-supplied packet length",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-75084",
"datePublished": "2026-10-14T16:46:01.701Z",
"dateReserved": "2026-08-17T16:17:47.262Z",
"dateUpdated": "2026-10-16T15:31:46.056Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19673 (GCVE-0-2026-19673)
Vulnerability from cvelistv5 – Published: 2026-10-14 16:45 – Updated: 2026-10-16 15:31
VLAI
EPSS
VEX
Title
Out-of-bounds read and net_buf length underflow in Zephyr Ethernet L2 when parsing a truncated VLAN header
Summary
ethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr. When the ethertype is 0x8100 and VLAN is enabled on the interface, the same buffer is reinterpreted as the 18-byte struct net_eth_vlan_hdr without re-checking the length: the VLAN TCI and the inner ethertype are read from offsets 14..17, past pkt->buffer->len, and hdr_len is raised to 18 so the subsequent net_buf_pull() removes more bytes than the buffer holds.
A single unauthenticated frame of 14 to 17 bytes carrying the VLAN ethertype triggers this. No knowledge of the node's VLAN configuration is needed: net_eth_get_vlan_iface() returns the base interface for the priority tag 0, and a broadcast destination address satisfies the "frame is for me" test, so a 16-byte broadcast frame with ethertype 0x8100 and TCI 0x0000 reaches the pull. Nothing in the receive path enforces the 60-byte Ethernet minimum — the USB CDC ECM and CDC NCM gadget classes in particular hand host-supplied frames of any non-zero length straight to net_recv_data().
With assertions enabled, net_buf_simple_pull() asserts and the node panics. In a production build (assertions and CONFIG_NET_BUF_HARDENING off) the uint16_t buffer length underflows to 65534 and buf->data is advanced past the end of the fragment's storage, so every later parser reads far outside the buffer and any net_buf_add() on that fragment computes tailroom from the underflowed length. The result is a reliable remote denial of service and out-of-bounds access with information-disclosure and corruption potential.
Only configurations built with CONFIG_NET_VLAN=y that have a VLAN enabled on the receiving Ethernet interface, and whose MAC does not strip VLAN tags in hardware (ETHERNET_HW_VLAN_TAG_STRIP), are affected. The fix rejects the frame before the tag is read, so hdr_len is thereafter either 14 or 18 with both sizes validated against pkt->buffer->len.
Severity
7.1 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 15:25 UTC
CWE
- CWE-125 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
1.12.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19673",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T15:25:19.143054Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T15:31:46.383Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/net/l2/ethernet/ethernet.c"
],
"programRoutines": [
{
"name": "ethernet_recv"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "1.12.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "ethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr. When the ethertype is 0x8100 and VLAN is enabled on the interface, the same buffer is reinterpreted as the 18-byte struct net_eth_vlan_hdr without re-checking the length: the VLAN TCI and the inner ethertype are read from offsets 14..17, past pkt-\u003ebuffer-\u003elen, and hdr_len is raised to 18 so the subsequent net_buf_pull() removes more bytes than the buffer holds.\n\nA single unauthenticated frame of 14 to 17 bytes carrying the VLAN ethertype triggers this. No knowledge of the node\u0027s VLAN configuration is needed: net_eth_get_vlan_iface() returns the base interface for the priority tag 0, and a broadcast destination address satisfies the \"frame is for me\" test, so a 16-byte broadcast frame with ethertype 0x8100 and TCI 0x0000 reaches the pull. Nothing in the receive path enforces the 60-byte Ethernet minimum \u2014 the USB CDC ECM and CDC NCM gadget classes in particular hand host-supplied frames of any non-zero length straight to net_recv_data().\n\nWith assertions enabled, net_buf_simple_pull() asserts and the node panics. In a production build (assertions and CONFIG_NET_BUF_HARDENING off) the uint16_t buffer length underflows to 65534 and buf-\u003edata is advanced past the end of the fragment\u0027s storage, so every later parser reads far outside the buffer and any net_buf_add() on that fragment computes tailroom from the underflowed length. The result is a reliable remote denial of service and out-of-bounds access with information-disclosure and corruption potential.\n\nOnly configurations built with CONFIG_NET_VLAN=y that have a VLAN enabled on the receiving Ethernet interface, and whose MAC does not strip VLAN tags in hardware (ETHERNET_HW_VLAN_TAG_STRIP), are affected. The fix rejects the frame before the tag is read, so hdr_len is thereafter either 14 or 18 with both sizes validated against pkt-\u003ebuffer-\u003elen."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.1,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T16:45:57.967Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/fd3c6fedf6b639977a80e52b680b15672c31f3ef"
},
{
"name": "GHSA-79rf-rwff-f4vg",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-79rf-rwff-f4vg"
}
],
"title": "Out-of-bounds read and net_buf length underflow in Zephyr Ethernet L2 when parsing a truncated VLAN header",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19673",
"datePublished": "2026-10-14T16:45:57.967Z",
"dateReserved": "2026-08-12T21:27:43.897Z",
"dateUpdated": "2026-10-16T15:31:46.383Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-75083 (GCVE-0-2026-75083)
Vulnerability from cvelistv5 – Published: 2026-10-14 16:45 – Updated: 2026-10-16 15:31
VLAI
EPSS
VEX
Title
Integer underflow of the radio-reported frame length causes an out-of-bounds write in the NXP KW41Z IEEE 802.15.4 driver
Summary
The receive path of the NXP KW41Z IEEE 802.15.4 driver, kw41z_rx() in drivers/ieee802154/ieee802154_kw41z.c, computed the payload size as pkt_len = len - KW41Z_FCS_LENGTH in a uint8_t, where len is the frame length reported by the radio. The interrupt handler kw41z_isr() obtained that length from the RX_FRAME_LENGTH field of the ZLL IRQSTS register — a copy of the PHY header length byte of the frame received over the air — and only rejected the value zero. A reported length of one therefore underflowed to pkt_len == 255.
Because the packet is allocated with NET_AF_UNSPEC on a non-Ethernet L2, net_pkt_rx_alloc_with_buffer() does not clamp the request to the interface MTU; with the default fixed-size buffer pool (CONFIG_NET_BUF_FIXED_DATA_SIZE, CONFIG_NET_BUF_DATA_SIZE=128) the allocation succeeded as a chain of two fragments. The subsequent register-to-buffer copy loops write into the first fragment only, so 255 bytes were written into a 128-byte net_buf data block, overrunning it by up to 127 bytes into adjacent network-buffer-pool memory, and reading up to 128 bytes past the end of the radio's PKT_BUFFER_RX register array.
The length field originates from an unauthenticated frame transmitted by any device within 802.15.4 radio range, and is captured by the hardware at PHY-header time — before frame filtering has completed — while the handler samples it after clearing the interrupt status, so an attacker flooding frames with a length byte of one can drive the underflow. The impact is memory corruption in the shared receive buffer pool from interrupt context, most plausibly a crash or corruption of other packets' data; the overflowing bytes are radio register contents rather than attacker-authored data, which bounds the integrity impact.
The fix rejects any length below KW41Z_FCS_LENGTH and additionally verifies net_buf_tailroom() of the first fragment before the copy loops, which also covers the CONFIG_NET_L2_OPENTHREAD variant of the size computation.
Severity
5.9 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 15:25 UTC
CWE
- CWE-191 - integer-overflow
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
1.8.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-75083",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T15:25:03.202886Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T15:31:46.531Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/ieee802154/ieee802154_kw41z.c"
],
"programRoutines": [
{
"name": "kw41z_isr"
},
{
"name": "kw41z_rx"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "1.8.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The receive path of the NXP KW41Z IEEE 802.15.4 driver, kw41z_rx() in drivers/ieee802154/ieee802154_kw41z.c, computed the payload size as pkt_len = len - KW41Z_FCS_LENGTH in a uint8_t, where len is the frame length reported by the radio. The interrupt handler kw41z_isr() obtained that length from the RX_FRAME_LENGTH field of the ZLL IRQSTS register \u2014 a copy of the PHY header length byte of the frame received over the air \u2014 and only rejected the value zero. A reported length of one therefore underflowed to pkt_len == 255.\n\nBecause the packet is allocated with NET_AF_UNSPEC on a non-Ethernet L2, net_pkt_rx_alloc_with_buffer() does not clamp the request to the interface MTU; with the default fixed-size buffer pool (CONFIG_NET_BUF_FIXED_DATA_SIZE, CONFIG_NET_BUF_DATA_SIZE=128) the allocation succeeded as a chain of two fragments. The subsequent register-to-buffer copy loops write into the first fragment only, so 255 bytes were written into a 128-byte net_buf data block, overrunning it by up to 127 bytes into adjacent network-buffer-pool memory, and reading up to 128 bytes past the end of the radio\u0027s PKT_BUFFER_RX register array.\n\nThe length field originates from an unauthenticated frame transmitted by any device within 802.15.4 radio range, and is captured by the hardware at PHY-header time \u2014 before frame filtering has completed \u2014 while the handler samples it after clearing the interrupt status, so an attacker flooding frames with a length byte of one can drive the underflow. The impact is memory corruption in the shared receive buffer pool from interrupt context, most plausibly a crash or corruption of other packets\u0027 data; the overflowing bytes are radio register contents rather than attacker-authored data, which bounds the integrity impact.\n\nThe fix rejects any length below KW41Z_FCS_LENGTH and additionally verifies net_buf_tailroom() of the first fragment before the copy loops, which also covers the CONFIG_NET_L2_OPENTHREAD variant of the size computation."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-191",
"description": "integer-overflow",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T16:45:56.541Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/51d71864578c08eb1a1201f87b46ec81c8609d62"
},
{
"name": "GHSA-2pwx-gg6f-535f",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2pwx-gg6f-535f"
}
],
"title": "Integer underflow of the radio-reported frame length causes an out-of-bounds write in the NXP KW41Z IEEE 802.15.4 driver",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-75083",
"datePublished": "2026-10-14T16:45:56.541Z",
"dateReserved": "2026-08-17T16:17:45.295Z",
"dateUpdated": "2026-10-16T15:31:46.531Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19940 (GCVE-0-2026-19940)
Vulnerability from cvelistv5 – Published: 2026-10-13 16:40 – Updated: 2026-10-14 19:26
VLAI
EPSS
VEX
Title
Bluetooth HFP AG reuses a connection slot while a delayable work item is still armed, corrupting kernel timeout bookkeeping
Summary
The Bluetooth Classic Hands-Free Profile Audio Gateway implementation in subsys/bluetooth/host/classic/hfp_ag.c keeps its struct bt_hfp_ag objects in a static pool indexed by ACL connection index. On link teardown, hfp_ag_disconnected() cancels ag->tx_work and the per-call work items and then clears ag->acl_conn, which marks the pool slot as free — but it leaves ag->ongoing_call_work (and ag->slc_work) untouched. The next connection that lands on the same slot enters hfp_ag_create(), whose only occupancy test is ag->acl_conn, and immediately executes memset(ag, 0, sizeof(struct bt_hfp_ag)) followed by k_work_init_delayable(). Zeroing and re-initialising a k_work_delayable whose struct _timeout node is still linked into the kernel timeout list leaves the kernel holding a reference to a node with NULL prev/next links.
ag->ongoing_call_work is armed by the remote peer: when a Hands-Free unit sends AT+CIND? during Service Level Connection establishment and the application provides the asynchronous get_ongoing_call callback, the AG schedules the work for CONFIG_BT_HFP_AG_GET_ONGOING_CALL_TIMEOUT milliseconds (default 10000). The timer is cancelled only if the application answers in time via bt_hfp_ag_ongoing_calls(). A peer that sends AT+CIND?, then disconnects the HFP RFCOMM DLC, then immediately re-opens it on the same ACL link, reuses the same pool slot deterministically while the timeout is still pending — the AG's RFCOMM server accept path (hfp_ag_accept()) calls hfp_ag_create() directly, so the remote side drives both teardown and re-creation.
The result is corruption of the kernel's timeout list: sys_dlist_remove() on the zeroed node performs writes through NULL pointers from the clock-announce path, and rescheduling the re-initialised work re-inserts a node the list already references, creating a cycle that the announce loop walks with interrupts locked. The observable impact is a fault or hang of the whole system, i.e. a denial of service reachable from Bluetooth radio range; no attacker-controlled data is written, so this does not by itself yield code execution. Exposure is limited to builds with CONFIG_BT_HFP_AG (marked experimental and disabled by default) whose application implements the asynchronous get_ongoing_call callback.
Severity
6.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-14 19:26 UTC
CWE
- CWE-416 - use-after-free
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.2.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19940",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-14T19:26:45.572487Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T19:26:59.593Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/host/classic/hfp_ag.c"
],
"programRoutines": [
{
"name": "hfp_ag_create"
},
{
"name": "hfp_ag_disconnected"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "4.2.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Bluetooth Classic Hands-Free Profile Audio Gateway implementation in subsys/bluetooth/host/classic/hfp_ag.c keeps its struct bt_hfp_ag objects in a static pool indexed by ACL connection index. On link teardown, hfp_ag_disconnected() cancels ag-\u003etx_work and the per-call work items and then clears ag-\u003eacl_conn, which marks the pool slot as free \u2014 but it leaves ag-\u003eongoing_call_work (and ag-\u003eslc_work) untouched. The next connection that lands on the same slot enters hfp_ag_create(), whose only occupancy test is ag-\u003eacl_conn, and immediately executes memset(ag, 0, sizeof(struct bt_hfp_ag)) followed by k_work_init_delayable(). Zeroing and re-initialising a k_work_delayable whose struct _timeout node is still linked into the kernel timeout list leaves the kernel holding a reference to a node with NULL prev/next links.\n\nag-\u003eongoing_call_work is armed by the remote peer: when a Hands-Free unit sends AT+CIND? during Service Level Connection establishment and the application provides the asynchronous get_ongoing_call callback, the AG schedules the work for CONFIG_BT_HFP_AG_GET_ONGOING_CALL_TIMEOUT milliseconds (default 10000). The timer is cancelled only if the application answers in time via bt_hfp_ag_ongoing_calls(). A peer that sends AT+CIND?, then disconnects the HFP RFCOMM DLC, then immediately re-opens it on the same ACL link, reuses the same pool slot deterministically while the timeout is still pending \u2014 the AG\u0027s RFCOMM server accept path (hfp_ag_accept()) calls hfp_ag_create() directly, so the remote side drives both teardown and re-creation.\n\nThe result is corruption of the kernel\u0027s timeout list: sys_dlist_remove() on the zeroed node performs writes through NULL pointers from the clock-announce path, and rescheduling the re-initialised work re-inserts a node the list already references, creating a cycle that the announce loop walks with interrupts locked. The observable impact is a fault or hang of the whole system, i.e. a denial of service reachable from Bluetooth radio range; no attacker-controlled data is written, so this does not by itself yield code execution. Exposure is limited to builds with CONFIG_BT_HFP_AG (marked experimental and disabled by default) whose application implements the asynchronous get_ongoing_call callback."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "use-after-free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-13T16:40:10.541Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/204c36b896fe8d68ca3cb3d00216f245f91d14be"
},
{
"name": "GHSA-v47w-8959-rx62",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-v47w-8959-rx62"
}
],
"title": "Bluetooth HFP AG reuses a connection slot while a delayable work item is still armed, corrupting kernel timeout bookkeeping",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19940",
"datePublished": "2026-10-13T16:40:10.541Z",
"dateReserved": "2026-08-15T13:31:23.585Z",
"dateUpdated": "2026-10-14T19:26:59.593Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19939 (GCVE-0-2026-19939)
Vulnerability from cvelistv5 – Published: 2026-10-13 16:39 – Updated: 2026-10-14 18:49
VLAI
EPSS
VEX
Title
Bluetooth Classic AVDTP: stale timeout work on signalling-channel disconnect leads to kernel timeout-list corruption
Summary
The AVDTP signalling layer arms a 6-second command timeout (AVDTP_TIMEOUT) in avdtp_send_cmd() whenever the local device issues an AVDTP request. Every response handler in subsys/bluetooth/host/classic/avdtp.c cancels session->timeout_work before clearing the pending request, but bt_avdtp_l2cap_disconnected() only cleared session->req and left the delayable work armed. The struct bt_avdtp session is the first member of struct bt_a2dp, whose instances live in a static per-connection array, and a2dp_get_connection() in subsys/bluetooth/host/classic/a2dp.c wipes a slot with memset() as soon as session->br_chan.chan.conn is NULL — which the L2CAP layer arranges immediately after the disconnect callback returns.
A remote Bluetooth BR/EDR peer triggers the condition by opening the AVDTP signalling channel, letting the local application issue an AVDTP procedure (the standard A2DP flow issues bt_a2dp_discover() from the connected callback), then tearing the signalling channel down without responding and re-opening it within the remaining timeout window. The reconnect reaches a2dp_accept() → a2dp_get_connection(), which zeroes the whole struct bt_a2dp while the work item's struct _timeout is still linked into the kernel's global timeout list. Both the disconnect and the reconnect instants are chosen by the attacker, so no race has to be won; an encrypted BR/EDR link is required, and CONFIG_BT_A2DP (experimental) must be enabled.
With the default CONFIG_TIMEOUT_BACKEND_DLIST backend the kernel decides a timeout is inactive by testing whether its list node is linked, so after the memset() the kernel treats a node that is still on the global timeout list as free: the announce path pops a node whose links and handler pointer are NULL, and the next bt_work_reschedule() on the recycled session re-inserts the same node into a list that already contains it. The consequence is corruption of the single kernel data structure every timer, timeslice and sleep depends on — writes through zeroed or stale list pointers and a NULL handler dispatch — producing a system-wide crash or hang rather than a fault confined to the A2DP session.
The fix cancels session->timeout_work at the top of bt_avdtp_l2cap_disconnected() and moves k_work_init_delayable() from avdtp_send_cmd() to the session-establishment paths bt_avdtp_connect() and bt_avdtp_l2cap_accept(), so the work item is always initialized before a disconnect callback can run.
Severity
6.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-14 18:49 UTC
CWE
- CWE-825 - memory-safety
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.7.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19939",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-14T18:49:00.544306Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T18:49:17.902Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/host/classic/avdtp.c"
],
"programRoutines": [
{
"name": "bt_avdtp_l2cap_disconnected"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "3.7.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The AVDTP signalling layer arms a 6-second command timeout (AVDTP_TIMEOUT) in avdtp_send_cmd() whenever the local device issues an AVDTP request. Every response handler in subsys/bluetooth/host/classic/avdtp.c cancels session-\u003etimeout_work before clearing the pending request, but bt_avdtp_l2cap_disconnected() only cleared session-\u003ereq and left the delayable work armed. The struct bt_avdtp session is the first member of struct bt_a2dp, whose instances live in a static per-connection array, and a2dp_get_connection() in subsys/bluetooth/host/classic/a2dp.c wipes a slot with memset() as soon as session-\u003ebr_chan.chan.conn is NULL \u2014 which the L2CAP layer arranges immediately after the disconnect callback returns.\n\nA remote Bluetooth BR/EDR peer triggers the condition by opening the AVDTP signalling channel, letting the local application issue an AVDTP procedure (the standard A2DP flow issues bt_a2dp_discover() from the connected callback), then tearing the signalling channel down without responding and re-opening it within the remaining timeout window. The reconnect reaches a2dp_accept() \u2192 a2dp_get_connection(), which zeroes the whole struct bt_a2dp while the work item\u0027s struct _timeout is still linked into the kernel\u0027s global timeout list. Both the disconnect and the reconnect instants are chosen by the attacker, so no race has to be won; an encrypted BR/EDR link is required, and CONFIG_BT_A2DP (experimental) must be enabled.\n\nWith the default CONFIG_TIMEOUT_BACKEND_DLIST backend the kernel decides a timeout is inactive by testing whether its list node is linked, so after the memset() the kernel treats a node that is still on the global timeout list as free: the announce path pops a node whose links and handler pointer are NULL, and the next bt_work_reschedule() on the recycled session re-inserts the same node into a list that already contains it. The consequence is corruption of the single kernel data structure every timer, timeslice and sleep depends on \u2014 writes through zeroed or stale list pointers and a NULL handler dispatch \u2014 producing a system-wide crash or hang rather than a fault confined to the A2DP session.\n\nThe fix cancels session-\u003etimeout_work at the top of bt_avdtp_l2cap_disconnected() and moves k_work_init_delayable() from avdtp_send_cmd() to the session-establishment paths bt_avdtp_connect() and bt_avdtp_l2cap_accept(), so the work item is always initialized before a disconnect callback can run."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-825",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-13T16:39:16.681Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/a10d18c3be9d1a968574dbfbce6baee58ea398e8"
},
{
"name": "GHSA-9mww-f3h4-mq95",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-9mww-f3h4-mq95"
}
],
"title": "Bluetooth Classic AVDTP: stale timeout work on signalling-channel disconnect leads to kernel timeout-list corruption",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19939",
"datePublished": "2026-10-13T16:39:16.681Z",
"dateReserved": "2026-08-15T13:31:21.855Z",
"dateUpdated": "2026-10-14T18:49:17.902Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19938 (GCVE-0-2026-19938)
Vulnerability from cvelistv5 – Published: 2026-10-12 23:19 – Updated: 2026-10-14 19:17
VLAI
EPSS
VEX
Title
Use-after-free of an ATT PDU buffer when signing an outgoing Bluetooth ATT Signed Write Command fails
Summary
The Bluetooth host's ATT transmit path releases a buffer it does not own when signing fails. chan_send() in subsys/bluetooth/host/att.c documents (and every other error exit implements) the contract that on failure the caller retains ownership of the net_buf; the BT_ATT_OP_SIGNED_WRITE_CMD branch instead called net_buf_unref(buf) when bt_smp_sign() returned an error and then returned that error to the caller. The callers act on the contract: process_queue() re-queues the buffer with k_queue_prepend(), bt_att_chan_send_rsp() puts it back on chan->tx_queue, bt_att_chan_req_send() restores it into the request, and att_req_retry() unreferences it — so the already-freed buffer was re-queued, later dereferenced, and eventually freed again.
An ATT Signed Write Command is produced when an application calls bt_gatt_write_without_response_cb() with sign set on an unencrypted connection. bt_smp_sign() fails whenever no local CSRK exists for the peer (-ENOENT), and whether one exists is negotiated with the peer: smp_distribute_keys() stores a local CSRK only when the peer's pairing key-distribution field requests the signing key and bonding was agreed. A peer can therefore pair without accepting the CSRK, pair with No Bonding, remain unpaired, or keep the link unencrypted, and the victim's next signed write takes the failing path. Because struct net_buf's node field is simultaneously the linkage word for the ATT TX FIFO, for the deferred-destroy list used by the att_pool destroy callback att_tx_destroy(), and for the pool free list, the mishandled buffer corrupts these lists and can be re-issued by bt_att_create_pdu() to a new PDU while the ATT TX path still holds it.
The same branch also saved the net_buf_simple_state only after signing, so a buffer restored after a bt_l2cap_send_pdu() failure kept its 12-octet signature; a subsequent retry re-signed it and appended a second signature with net_buf_add(buf, 12) to a buffer that bt_att_create_pdu() sized for exactly one, writing past the end of the pooled buffer in builds where the net_buf tailroom assertion is compiled out.
Impact is host-side memory corruption in the Bluetooth stack: list corruption, a pooled ATT buffer with two owners (wrong PDU contents transmitted, or a double free when the queues are drained at disconnect), and a bounded out-of-bounds write on the retry path — typically observed as a crash or assertion failure. Exposure requires the deprecated CONFIG_BT_SIGNING to be enabled and an application that actually issues signed writes; in that configuration the triggering condition is under the remote peer's control.
Severity
5.9 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-14 19:17 UTC
CWE
- CWE-416 - use-after-free
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
2.3.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19938",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-14T19:17:29.614317Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T19:17:39.405Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/host/att.c"
],
"programRoutines": [
{
"name": "bt_att_send"
},
{
"name": "chan_send"
},
{
"name": "process_queue"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "2.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Bluetooth host\u0027s ATT transmit path releases a buffer it does not own when signing fails. chan_send() in subsys/bluetooth/host/att.c documents (and every other error exit implements) the contract that on failure the caller retains ownership of the net_buf; the BT_ATT_OP_SIGNED_WRITE_CMD branch instead called net_buf_unref(buf) when bt_smp_sign() returned an error and then returned that error to the caller. The callers act on the contract: process_queue() re-queues the buffer with k_queue_prepend(), bt_att_chan_send_rsp() puts it back on chan-\u003etx_queue, bt_att_chan_req_send() restores it into the request, and att_req_retry() unreferences it \u2014 so the already-freed buffer was re-queued, later dereferenced, and eventually freed again.\n\nAn ATT Signed Write Command is produced when an application calls bt_gatt_write_without_response_cb() with sign set on an unencrypted connection. bt_smp_sign() fails whenever no local CSRK exists for the peer (-ENOENT), and whether one exists is negotiated with the peer: smp_distribute_keys() stores a local CSRK only when the peer\u0027s pairing key-distribution field requests the signing key and bonding was agreed. A peer can therefore pair without accepting the CSRK, pair with No Bonding, remain unpaired, or keep the link unencrypted, and the victim\u0027s next signed write takes the failing path. Because struct net_buf\u0027s node field is simultaneously the linkage word for the ATT TX FIFO, for the deferred-destroy list used by the att_pool destroy callback att_tx_destroy(), and for the pool free list, the mishandled buffer corrupts these lists and can be re-issued by bt_att_create_pdu() to a new PDU while the ATT TX path still holds it.\n\nThe same branch also saved the net_buf_simple_state only after signing, so a buffer restored after a bt_l2cap_send_pdu() failure kept its 12-octet signature; a subsequent retry re-signed it and appended a second signature with net_buf_add(buf, 12) to a buffer that bt_att_create_pdu() sized for exactly one, writing past the end of the pooled buffer in builds where the net_buf tailroom assertion is compiled out.\n\nImpact is host-side memory corruption in the Bluetooth stack: list corruption, a pooled ATT buffer with two owners (wrong PDU contents transmitted, or a double free when the queues are drained at disconnect), and a bounded out-of-bounds write on the retry path \u2014 typically observed as a crash or assertion failure. Exposure requires the deprecated CONFIG_BT_SIGNING to be enabled and an application that actually issues signed writes; in that configuration the triggering condition is under the remote peer\u0027s control."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "use-after-free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T23:19:55.449Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/ba8627d91c8ce15c26224cbc7f7f92bb66f56b03"
},
{
"name": "GHSA-p3r4-qw98-j59m",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-p3r4-qw98-j59m"
}
],
"title": "Use-after-free of an ATT PDU buffer when signing an outgoing Bluetooth ATT Signed Write Command fails",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19938",
"datePublished": "2026-10-12T23:19:55.449Z",
"dateReserved": "2026-08-15T13:31:20.143Z",
"dateUpdated": "2026-10-14T19:17:39.405Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19937 (GCVE-0-2026-19937)
Vulnerability from cvelistv5 – Published: 2026-10-12 23:19 – Updated: 2026-10-14 19:17
VLAI
EPSS
VEX
Title
Bluetooth Mesh Access layer permanently leaks delayable-message contexts, disabling all model responses
Summary
The Bluetooth Mesh Access layer delayable-message machinery in subsys/bluetooth/mesh/delayable_msg.c manages a static pool of CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT message contexts (default 4) threaded onto a free_ctx or busy_ctx list. release_delayable_msg_ctx() returned a context to free_ctx only when sys_slist_find_and_remove() found it on busy_ctx. The chunk-exhaustion error path in bt_mesh_delayable_msg_manage() releases a context that was already popped off free_ctx but not yet inserted on busy_ctx, so the context was appended to neither list and was permanently lost from the pool. Because bt_mesh_delayable_msg_init() runs only once from bt_mesh_init(), and node reset/suspend only drain busy_ctx, the loss survives unprovision, re-provision and suspend/resume — it is cleared only by a reboot.
The error path is reached when the chunk pool (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, default 40 chunks) is short of the chunks a new delayed message needs and the oldest pending message cannot be flushed because bt_mesh_access_send() returns -EBUSY or -ENOBUFS (all segmented-TX contexts busy, or advertising/segment buffers exhausted). A peer that is provisioned into the mesh network — holding a valid NetKey plus an AppKey or DevKey bound to a server model — can drive both conditions by flooding the victim with requests that elicit segmented responses while withholding the Segment Acknowledgment, which keeps the transmit contexts occupied while queued responses hold the chunk pool. Each further request that arrives in that window leaks one context.
Once the pool is drained, bt_mesh_delayable_msg_manage() returns -ENOMEM for every subsequent send and bt_mesh_model_send() propagates that error with no fallback to an immediate transmit. Since CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED are both enabled by default, ctx->rnd_delay is set for every received access message, so all replies from Configuration Server, Health Server and application server models are silently dropped. The node keeps receiving and processing traffic but never answers, a persistent denial of service until the device is restarted. There is no memory corruption, information disclosure or integrity impact; releases before the fix compute the chunk count from the transmit buffer capacity rather than its payload length, making chunk-pool starvation — and therefore the leak — considerably easier to provoke.
Severity
5.7 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-14 19:16 UTC
CWE
- CWE-772 - dos
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.6.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19937",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-14T19:16:51.437665Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T19:17:03.644Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/mesh/delayable_msg.c"
],
"programRoutines": [
{
"name": "bt_mesh_delayable_msg_manage"
},
{
"name": "release_delayable_msg_ctx"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "3.6.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Bluetooth Mesh Access layer delayable-message machinery in subsys/bluetooth/mesh/delayable_msg.c manages a static pool of CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT message contexts (default 4) threaded onto a free_ctx or busy_ctx list. release_delayable_msg_ctx() returned a context to free_ctx only when sys_slist_find_and_remove() found it on busy_ctx. The chunk-exhaustion error path in bt_mesh_delayable_msg_manage() releases a context that was already popped off free_ctx but not yet inserted on busy_ctx, so the context was appended to neither list and was permanently lost from the pool. Because bt_mesh_delayable_msg_init() runs only once from bt_mesh_init(), and node reset/suspend only drain busy_ctx, the loss survives unprovision, re-provision and suspend/resume \u2014 it is cleared only by a reboot.\n\nThe error path is reached when the chunk pool (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, default 40 chunks) is short of the chunks a new delayed message needs and the oldest pending message cannot be flushed because bt_mesh_access_send() returns -EBUSY or -ENOBUFS (all segmented-TX contexts busy, or advertising/segment buffers exhausted). A peer that is provisioned into the mesh network \u2014 holding a valid NetKey plus an AppKey or DevKey bound to a server model \u2014 can drive both conditions by flooding the victim with requests that elicit segmented responses while withholding the Segment Acknowledgment, which keeps the transmit contexts occupied while queued responses hold the chunk pool. Each further request that arrives in that window leaks one context.\n\nOnce the pool is drained, bt_mesh_delayable_msg_manage() returns -ENOMEM for every subsequent send and bt_mesh_model_send() propagates that error with no fallback to an immediate transmit. Since CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED are both enabled by default, ctx-\u003ernd_delay is set for every received access message, so all replies from Configuration Server, Health Server and application server models are silently dropped. The node keeps receiving and processing traffic but never answers, a persistent denial of service until the device is restarted. There is no memory corruption, information disclosure or integrity impact; releases before the fix compute the chunk count from the transmit buffer capacity rather than its payload length, making chunk-pool starvation \u2014 and therefore the leak \u2014 considerably easier to provoke."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.7,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-772",
"description": "dos",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T23:19:54.254Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/097001f187ba2764e9ef1cc7113b8da525bf741c"
},
{
"name": "GHSA-5rrx-xww6-5xrh",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-5rrx-xww6-5xrh"
}
],
"title": "Bluetooth Mesh Access layer permanently leaks delayable-message contexts, disabling all model responses",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19937",
"datePublished": "2026-10-12T23:19:54.254Z",
"dateReserved": "2026-08-15T13:31:18.438Z",
"dateUpdated": "2026-10-14T19:17:03.644Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19936 (GCVE-0-2026-19936)
Vulnerability from cvelistv5 – Published: 2026-10-12 23:19 – Updated: 2026-10-14 19:16
VLAI
EPSS
VEX
Title
Bluetooth Mesh delayable message queue: unsynchronized list access leads to NULL pointer dereference
Summary
The Bluetooth Mesh Access-layer delayable message queue in subsys/bluetooth/mesh/delayable_msg.c shares three intrusive lists (busy_ctx, free_ctx, free_chunks) and one k_work_delayable between two cooperative threads with no synchronization: bt_mesh_delayable_msg_manage() runs on the Bluetooth host RX thread, while delayable_msg_handler() runs on the system workqueue. Both block while the lists are in an intermediate state — the enqueuer in bt_rand(), both in bt_mesh_access_send() — which lets the other context observe torn state. delayable_msg_handler() used the result of sys_slist_get() on busy_ctx without a NULL check, and allocate_delayable_msg_ctx() tested sys_slist_is_empty() and then assumed a separate sys_slist_get() would succeed.
Because CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED default to y, every model response to a received mesh message is parked on this queue, so the enqueuer runs as a direct consequence of inbound traffic. A peer that can get access-layer messages accepted by a model (it must hold the NetKey and a bound AppKey, so a legitimate or compromised network member) controls the arrival rate, the size of the elicited responses and the destination address, and thereby controls occupancy of the 4-entry context pool and the 40-entry chunk pool. Exhausting the chunk pool forces bt_mesh_delayable_msg_manage() down the purge path, which sends and releases the only queued message and leaves busy_ctx empty while the delayable work item is still armed; if the enqueuer then yields, the handler runs against the empty list.
The result is a read-modify-write through a NULL-based pointer (pending_msg->fired_time += 10) at a fixed low address on the system workqueue thread. On typical targets that faults, aborting the system workqueue thread — which stops all workqueue-driven functionality, including the mesh timing machinery — or resetting the node, so the impact is loss of availability of the affected node. The write value and address are fixed and no attacker-controlled length or index is involved, so this is not exploitable for memory corruption or code execution. The same unsynchronized window also allowed one message context to be selected and released by two contexts at once, producing duplicated transmissions, duplicated send-completion callbacks and crossed chunk ownership.
The fix serializes every list mutation with a k_spinlock that is never held across a blocking call, makes push_msg_from_delayable_msgs() detach the queue head atomically so a message being sent is on no list, removes the unchecked sys_slist_get() from delayable_msg_handler(), and drops any message that reaches the front of the queue while the stack is suspended or reset.
Severity
4.8 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-14 19:16 UTC
CWE
- CWE-362 - race
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.6.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19936",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-14T19:16:12.334462Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T19:16:26.893Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/mesh/delayable_msg.c"
],
"programRoutines": [
{
"name": "allocate_delayable_msg_ctx"
},
{
"name": "bt_mesh_delayable_msg_manage"
},
{
"name": "delayable_msg_handler"
},
{
"name": "push_msg_from_delayable_msgs"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "3.6.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Bluetooth Mesh Access-layer delayable message queue in subsys/bluetooth/mesh/delayable_msg.c shares three intrusive lists (busy_ctx, free_ctx, free_chunks) and one k_work_delayable between two cooperative threads with no synchronization: bt_mesh_delayable_msg_manage() runs on the Bluetooth host RX thread, while delayable_msg_handler() runs on the system workqueue. Both block while the lists are in an intermediate state \u2014 the enqueuer in bt_rand(), both in bt_mesh_access_send() \u2014 which lets the other context observe torn state. delayable_msg_handler() used the result of sys_slist_get() on busy_ctx without a NULL check, and allocate_delayable_msg_ctx() tested sys_slist_is_empty() and then assumed a separate sys_slist_get() would succeed.\n\nBecause CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED default to y, every model response to a received mesh message is parked on this queue, so the enqueuer runs as a direct consequence of inbound traffic. A peer that can get access-layer messages accepted by a model (it must hold the NetKey and a bound AppKey, so a legitimate or compromised network member) controls the arrival rate, the size of the elicited responses and the destination address, and thereby controls occupancy of the 4-entry context pool and the 40-entry chunk pool. Exhausting the chunk pool forces bt_mesh_delayable_msg_manage() down the purge path, which sends and releases the only queued message and leaves busy_ctx empty while the delayable work item is still armed; if the enqueuer then yields, the handler runs against the empty list.\n\nThe result is a read-modify-write through a NULL-based pointer (pending_msg-\u003efired_time += 10) at a fixed low address on the system workqueue thread. On typical targets that faults, aborting the system workqueue thread \u2014 which stops all workqueue-driven functionality, including the mesh timing machinery \u2014 or resetting the node, so the impact is loss of availability of the affected node. The write value and address are fixed and no attacker-controlled length or index is involved, so this is not exploitable for memory corruption or code execution. The same unsynchronized window also allowed one message context to be selected and released by two contexts at once, producing duplicated transmissions, duplicated send-completion callbacks and crossed chunk ownership.\n\nThe fix serializes every list mutation with a k_spinlock that is never held across a blocking call, makes push_msg_from_delayable_msgs() detach the queue head atomically so a message being sent is on no list, removes the unchecked sys_slist_get() from delayable_msg_handler(), and drops any message that reaches the front of the queue while the stack is suspended or reset."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-362",
"description": "race",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-12T23:19:53.113Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/0a6da68955f454edc41e4b916e05c3b974209fe4"
},
{
"name": "GHSA-4p55-7h77-fhgr",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4p55-7h77-fhgr"
}
],
"title": "Bluetooth Mesh delayable message queue: unsynchronized list access leads to NULL pointer dereference",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19936",
"datePublished": "2026-10-12T23:19:53.113Z",
"dateReserved": "2026-08-15T13:31:16.656Z",
"dateUpdated": "2026-10-14T19:16:26.893Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19740 (GCVE-0-2026-19740)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:15 – Updated: 2026-10-16 17:07
VLAI
EPSS
VEX
Title
Bluetooth LE Controller: retained RX node leak and reachable assertion in the PHY Update procedure
Summary
The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UPDATE_IND so that it can later be reused for the host notification when the update instant is reached (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, and the node is deliberately not recycled while marked NODE_RX_TYPE_RETAIN). The invalid-PDU arms of llcp_lp_pu_rx() and llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completed the procedure via llcp_lr_complete() / llcp_rr_complete() without first releasing that retained node, so the procedure context — the only remaining reference to the node — was freed while the node was still held out of the receive pool.
A peer device on an established LE connection can drive this deterministically and without pairing or encryption. Against a peripheral it sends LL_PHY_REQ, receives LL_PHY_RSP, sends a valid LL_PHY_UPDATE_IND with an instant a few connection events in the future (so the node becomes retained), and then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ; ull_cp_rx() routes it to the active remote PHY Update procedure, which takes the invalid-PDU path. The mirror case applies to a locally initiated PHY Update followed by an LL_REJECT_IND.
In the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both default y) the violated invariant in llcp_lr_check_done() / llcp_rr_check_done() triggers a controller assertion, ending in k_oops() (or k_panic()) — a single crafted PDU sequence from radio range faults the device. With those assertions compiled out, each attempt silently leaks one receive PDU node and its memq link; because the controller receive pool is small (PDU_RX_CNT, driven by CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1) and each attempt costs the attacker only a reconnect, a few repetitions exhaust the pool and leave Bluetooth inoperable until reboot. On releases v3.4.0 through v3.7.x the assertion is never reached, whatever the configuration, so every attempt leaks silently.
The impact is limited to availability: the orphaned node leaves no dangling pointer that is later dereferenced and is never delivered to the host, so there is no memory corruption or information disclosure. The same pull request applies the identical release to the Connection Update and CIS-create procedures, whose invalid-PDU arms had the same omission.
Severity
6.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 17:06 UTC
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.4.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19740",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T17:06:45.803944Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T17:07:22.546Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c"
],
"programRoutines": [
{
"name": "llcp_lp_pu_rx"
},
{
"name": "llcp_rp_pu_rx"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UPDATE_IND so that it can later be reused for the host notification when the update instant is reached (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, and the node is deliberately not recycled while marked NODE_RX_TYPE_RETAIN). The invalid-PDU arms of llcp_lp_pu_rx() and llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completed the procedure via llcp_lr_complete() / llcp_rr_complete() without first releasing that retained node, so the procedure context \u2014 the only remaining reference to the node \u2014 was freed while the node was still held out of the receive pool.\n\nA peer device on an established LE connection can drive this deterministically and without pairing or encryption. Against a peripheral it sends LL_PHY_REQ, receives LL_PHY_RSP, sends a valid LL_PHY_UPDATE_IND with an instant a few connection events in the future (so the node becomes retained), and then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ; ull_cp_rx() routes it to the active remote PHY Update procedure, which takes the invalid-PDU path. The mirror case applies to a locally initiated PHY Update followed by an LL_REJECT_IND.\n\nIn the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both default y) the violated invariant in llcp_lr_check_done() / llcp_rr_check_done() triggers a controller assertion, ending in k_oops() (or k_panic()) \u2014 a single crafted PDU sequence from radio range faults the device. With those assertions compiled out, each attempt silently leaks one receive PDU node and its memq link; because the controller receive pool is small (PDU_RX_CNT, driven by CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1) and each attempt costs the attacker only a reconnect, a few repetitions exhaust the pool and leave Bluetooth inoperable until reboot. On releases v3.4.0 through v3.7.x the assertion is never reached, whatever the configuration, so every attempt leaks silently.\n\nThe impact is limited to availability: the orphaned node leaves no dangling pointer that is later dereferenced and is never delivered to the host, so there is no memory corruption or information disclosure. The same pull request applies the identical release to the Connection Update and CIS-create procedures, whose invalid-PDU arms had the same omission."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-401",
"description": "dos",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-459",
"description": "dos",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-617",
"description": "dos",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-772",
"description": "dos",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:15:08.080Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/06bf10e3de16b57b864f969330188b59f7d69a63"
},
{
"name": "GHSA-rgw4-3qr8-pp36",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-rgw4-3qr8-pp36"
}
],
"title": "Bluetooth LE Controller: retained RX node leak and reachable assertion in the PHY Update procedure",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19740",
"datePublished": "2026-10-11T17:15:08.080Z",
"dateReserved": "2026-08-13T13:46:34.001Z",
"dateUpdated": "2026-10-16T17:07:22.546Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19739 (GCVE-0-2026-19739)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:15 – Updated: 2026-10-16 15:51
VLAI
EPSS
VEX
Title
Bluetooth LE controller leaks a retained RX node when an unexpected LL Control PDU arrives during a Connection Update
Summary
The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update / Connection Parameter procedure waits for its instant, so the node can later carry the host notification (llcp_rx_node_retain(), which marks it NODE_RX_TYPE_RETAIN and thereby suppresses the normal recycling in ull.c). The default: arm of llcp_rp_cu_rx() and llcp_lp_cu_rx() — the "invalid PDU, terminate the connection" path — completed the procedure without releasing that retained node. llcp_rr_check_done() then dequeued and freed the procedure context with ctx->node_ref.rx still pointing at the retained node, dropping the last reference to it.
A peer device in radio range can reach this without pairing, bonding, or encryption. Against a peripheral, the peer sends a well-formed LL_CONNECTION_UPDATE_IND with an instant a few connection events in the future (the node is retained and the procedure enters RP_CU_STATE_WAIT_INSTANT), then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ. ull_cp_rx() routes that PDU into the active remote Connection Update procedure, which takes the invalid-PDU path. The central role is reachable symmetrically after accepting an LL_CONNECTION_PARAM_REQ, and the local-procedure variant is reachable with LL_REJECT_IND.
With CONFIG_BT_CTLR_ASSERT_DEBUG enabled (its default), the resulting state violates the invariant asserted in llcp_rr_check_done(), so the two-PDU sequence produces an immediate fatal error in the controller. With those asserts disabled, each occurrence permanently loses one node from the controller's small fixed RX pool (sized from CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1); repeating the sequence across reconnections exhausts the pool, after which the link-layer receive path operates on a NULL node. The impact is an unauthenticated, remotely triggerable denial of service persisting until reboot; there is no memory-disclosure or memory-corruption consequence, since the leaked node simply becomes unreachable.
Severity
6.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 15:50 UTC
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.4.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19739",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T15:50:37.226993Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T15:51:02.837Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c"
],
"programRoutines": [
{
"name": "llcp_lp_cu_rx"
},
{
"name": "llcp_rp_cu_rx"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update / Connection Parameter procedure waits for its instant, so the node can later carry the host notification (llcp_rx_node_retain(), which marks it NODE_RX_TYPE_RETAIN and thereby suppresses the normal recycling in ull.c). The default: arm of llcp_rp_cu_rx() and llcp_lp_cu_rx() \u2014 the \"invalid PDU, terminate the connection\" path \u2014 completed the procedure without releasing that retained node. llcp_rr_check_done() then dequeued and freed the procedure context with ctx-\u003enode_ref.rx still pointing at the retained node, dropping the last reference to it.\n\nA peer device in radio range can reach this without pairing, bonding, or encryption. Against a peripheral, the peer sends a well-formed LL_CONNECTION_UPDATE_IND with an instant a few connection events in the future (the node is retained and the procedure enters RP_CU_STATE_WAIT_INSTANT), then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ. ull_cp_rx() routes that PDU into the active remote Connection Update procedure, which takes the invalid-PDU path. The central role is reachable symmetrically after accepting an LL_CONNECTION_PARAM_REQ, and the local-procedure variant is reachable with LL_REJECT_IND.\n\nWith CONFIG_BT_CTLR_ASSERT_DEBUG enabled (its default), the resulting state violates the invariant asserted in llcp_rr_check_done(), so the two-PDU sequence produces an immediate fatal error in the controller. With those asserts disabled, each occurrence permanently loses one node from the controller\u0027s small fixed RX pool (sized from CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1); repeating the sequence across reconnections exhausts the pool, after which the link-layer receive path operates on a NULL node. The impact is an unauthenticated, remotely triggerable denial of service persisting until reboot; there is no memory-disclosure or memory-corruption consequence, since the leaked node simply becomes unreachable."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-401",
"description": "dos",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-459",
"description": "dos",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-617",
"description": "dos",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-772",
"description": "dos",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:15:06.540Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/7b600129faaba8bb26dd5cb3e8f17ed1cb41ea7f"
},
{
"name": "GHSA-84v8-vgp5-4vc9",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-84v8-vgp5-4vc9"
}
],
"title": "Bluetooth LE controller leaks a retained RX node when an unexpected LL Control PDU arrives during a Connection Update",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19739",
"datePublished": "2026-10-11T17:15:06.540Z",
"dateReserved": "2026-08-13T13:46:31.915Z",
"dateUpdated": "2026-10-16T15:51:02.837Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19738 (GCVE-0-2026-19738)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:15 – Updated: 2026-10-16 15:49
VLAI
EPSS
VEX
Title
Retained RX node leak and reachable assertion in Bluetooth Controller CIS Create procedures
Summary
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.
Severity
6.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 15:49 UTC
CWE
- CWE-401 - dos
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.4.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19738",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T15:49:12.012353Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T15:49:46.768Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/controller/ll_sw/ull_llcp_cc.c"
],
"programRoutines": [
{
"name": "llcp_lp_cc_rx"
},
{
"name": "llcp_rp_cc_rx"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation retains an RX node (ctx-\u003enode_ref.rx, marked NODE_RX_TYPE_RETAIN) so it can later be reused as the host notification \u2014 on the peripheral while awaiting the Host\u0027s 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\u0027s memory.\n\nA 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.\n\nIn 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\u0027s 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 \u2014 the leaked node is orphaned, never reused or double-freed \u2014 and recovery requires a reboot."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-401",
"description": "dos",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:15:04.970Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/fde17f2c3de0118f3796c2a83958ee4ce4b5efd6"
},
{
"name": "GHSA-6mcj-5jw8-ff36",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6mcj-5jw8-ff36"
}
],
"title": "Retained RX node leak and reachable assertion in Bluetooth Controller CIS Create procedures",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19738",
"datePublished": "2026-10-11T17:15:04.970Z",
"dateReserved": "2026-08-13T13:46:29.882Z",
"dateUpdated": "2026-10-16T15:49:46.768Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19935 (GCVE-0-2026-19935)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:15 – Updated: 2026-10-16 15:48
VLAI
EPSS
VEX
Title
Use-after-free of an L2CAP CoC channel object in the Zephyr Bluetooth host: RX work item is not cancelled on channel teardown
Summary
The Bluetooth LE host queues received L2CAP connection-oriented channel (CoC) data for deferred processing through a struct k_work embedded in the channel object (le_chan->rx_work, handler l2cap_rx_process()) whenever the channel uses a dynamic PSM (0x0080-0x00FF). Channel teardown in l2cap_chan_destroy() in subsys/bluetooth/host/l2cap.c cancels the retransmission-timeout work and drains the RX FIFO, but never cancels rx_work. Because that work item was submitted to the system workqueue while HCI receive processing runs on the dedicated Bluetooth RX workqueue (CONFIG_BT_RECV_WORKQ_BT, the default), a queued rx_work item can outlive the channel it points into.
A remote, unauthenticated peer with an established CoC channel triggers this by sending a data K-frame immediately followed by an L2CAP Disconnect Request. The K-frame submits rx_work to the system workqueue; because both workqueue threads are cooperative and the Bluetooth RX workqueue runs at the higher priority (K_PRIO_COOP(CONFIG_BT_RX_PRIO) versus CONFIG_SYSTEM_WORKQUEUE_PRIORITY), the pending item cannot run before the following Disconnect Request is processed in le_disconn_req() -> l2cap_chan_del() -> l2cap_chan_destroy(). The stack then invokes the released() callback, which the API documents as meaning the stack has dropped all references and the application may free the channel memory.
The application therefore frees or re-accepts into an object that the system workqueue still holds in its pending list. If the memory is freed and reallocated, the workqueue later dereferences a list node and a handler function pointer read from reused memory; if the object is re-used for a later connection, l2cap_chan_add() calls k_work_init() on a still-enqueued work item, corrupting the workqueue's pending list so that unrelated work items are dropped or the queue spins on a looped list. A related variant lets l2cap_rx_process() run concurrently with teardown, racing the net_buf unref of le_chan->_sdu and the clearing of chan->conn.
The fix routes the channel RX work to the Bluetooth workqueue - the same context in which every teardown path runs - and adds an explicit k_work_cancel() of le_chan->rx_work in l2cap_chan_destroy(), so no reference to the channel survives the released() callback. Configurations without CONFIG_BT_L2CAP_DYNAMIC_CHANNEL, or that only use SIG-assigned PSMs (EATT 0x0027, OTS 0x0025) which take the inline receive path, are not affected.
Severity
7.5 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 15:48 UTC
CWE
- CWE-416 - use-after-free
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
2.0.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19935",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T15:48:18.823080Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T15:48:34.096Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/host/l2cap.c"
],
"programRoutines": [
{
"name": "l2cap_chan_destroy"
},
{
"name": "l2cap_chan_recv_queue"
},
{
"name": "l2cap_rx_process"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "2.0.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Bluetooth LE host queues received L2CAP connection-oriented channel (CoC) data for deferred processing through a struct k_work embedded in the channel object (le_chan-\u003erx_work, handler l2cap_rx_process()) whenever the channel uses a dynamic PSM (0x0080-0x00FF). Channel teardown in l2cap_chan_destroy() in subsys/bluetooth/host/l2cap.c cancels the retransmission-timeout work and drains the RX FIFO, but never cancels rx_work. Because that work item was submitted to the system workqueue while HCI receive processing runs on the dedicated Bluetooth RX workqueue (CONFIG_BT_RECV_WORKQ_BT, the default), a queued rx_work item can outlive the channel it points into.\n\nA remote, unauthenticated peer with an established CoC channel triggers this by sending a data K-frame immediately followed by an L2CAP Disconnect Request. The K-frame submits rx_work to the system workqueue; because both workqueue threads are cooperative and the Bluetooth RX workqueue runs at the higher priority (K_PRIO_COOP(CONFIG_BT_RX_PRIO) versus CONFIG_SYSTEM_WORKQUEUE_PRIORITY), the pending item cannot run before the following Disconnect Request is processed in le_disconn_req() -\u003e l2cap_chan_del() -\u003e l2cap_chan_destroy(). The stack then invokes the released() callback, which the API documents as meaning the stack has dropped all references and the application may free the channel memory.\n\nThe application therefore frees or re-accepts into an object that the system workqueue still holds in its pending list. If the memory is freed and reallocated, the workqueue later dereferences a list node and a handler function pointer read from reused memory; if the object is re-used for a later connection, l2cap_chan_add() calls k_work_init() on a still-enqueued work item, corrupting the workqueue\u0027s pending list so that unrelated work items are dropped or the queue spins on a looped list. A related variant lets l2cap_rx_process() run concurrently with teardown, racing the net_buf unref of le_chan-\u003e_sdu and the clearing of chan-\u003econn.\n\nThe fix routes the channel RX work to the Bluetooth workqueue - the same context in which every teardown path runs - and adds an explicit k_work_cancel() of le_chan-\u003erx_work in l2cap_chan_destroy(), so no reference to the channel survives the released() callback. Configurations without CONFIG_BT_L2CAP_DYNAMIC_CHANNEL, or that only use SIG-assigned PSMs (EATT 0x0027, OTS 0x0025) which take the inline receive path, are not affected."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.5,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "use-after-free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:15:03.386Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/22896cb8d6f23feffe4b637119fb3e974ac3bed8"
},
{
"name": "GHSA-6gp4-cwf7-2vp8",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6gp4-cwf7-2vp8"
}
],
"title": "Use-after-free of an L2CAP CoC channel object in the Zephyr Bluetooth host: RX work item is not cancelled on channel teardown",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19935",
"datePublished": "2026-10-11T17:15:03.386Z",
"dateReserved": "2026-08-15T13:31:14.966Z",
"dateUpdated": "2026-10-16T15:48:34.096Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19737 (GCVE-0-2026-19737)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:15 – Updated: 2026-10-16 15:46
VLAI
EPSS
VEX
Title
NULL pointer dereference in the ESP32 I2S driver when triggering an unsupported direction
Summary
i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH. The I2S_DIR_RX and I2S_DIR_TX branches read dev_cfg->rx.data->configured / dev_cfg->tx.data->configured without first checking the stream pointers. The device instantiation macro I2S_ESP32_STREAM_INIT() sets both .conf and .data to NULL for a direction the devicetree does not describe, so on an instance that wires only one direction — the normal shape for audio output or a worldsemi,ws2812-i2s LED strip — the other direction dereferences a NULL pointer instead of returning an error.
i2s_trigger() is a Zephyr syscall, and z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only the device object and the presence of the trigger API pointer; the dir argument is passed to the driver unvalidated. On a build with CONFIG_USERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2s_trigger() call naming the unwired direction and cause a load from address 0 in kernel mode. Among the Espressif parts that carry this driver, userspace is available in-tree only on RISC-V SoCs with CONFIG_RISCV_PMP, and v4.4.0 is the first release where that is buildable: the ESP32-C6 HPCORE selects RISCV_PMP when it is not built for MCUboot. ESP32-C5 in v4.4.x carries the same PMP-region and userspace linker support but does not select RISCV_PMP by default. Espressif Xtensa targets do not support Zephyr userspace, and in a non-userspace build the bad direction can only come from in-kernel application code.
The impact is limited to availability: the access is a read at offset 0 of the missing stream structure, so there is no attacker-controlled offset, no write primitive and no information disclosure. With the default fatal-error handler the resulting exception halts the system, giving an unprivileged user-mode thread a system-wide denial of service. The fix adds the same pointer check the I2S_DIR_BOTH branch already performed and returns -ENOSYS for a direction the instance does not implement; the driver's other entry points (i2s_esp32_config_check(), i2s_esp32_config_get(), i2s_esp32_read(), i2s_esp32_write()) already guarded the pointers, and a static audit found no equivalent unguarded path.
The driver defect is older than the affected range. The unguarded dereference is present from v4.2.0 (reached through i2s_esp32_trigger_stream(), whose if (stream) guard tests the address of a struct member and is never false) and takes its present i2s_esp32_trigger_check() form in v4.3.0. No in-tree Espressif configuration before v4.4.0 can run a user-mode thread, so in v4.2.x and v4.3.x the direction argument can only come from trusted kernel code. Those releases carry the bug but are not listed as affected; the fix has also been merged to v4.3-branch as hardening.
Severity
5.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 15:45 UTC
CWE
- CWE-476 - memory-safety
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.4.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19737",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T15:45:22.302843Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T15:46:16.400Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/i2s/i2s_esp32.c"
],
"programRoutines": [
{
"name": "i2s_esp32_trigger"
},
{
"name": "i2s_esp32_trigger_check"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "4.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH. The I2S_DIR_RX and I2S_DIR_TX branches read dev_cfg-\u003erx.data-\u003econfigured / dev_cfg-\u003etx.data-\u003econfigured without first checking the stream pointers. The device instantiation macro I2S_ESP32_STREAM_INIT() sets both .conf and .data to NULL for a direction the devicetree does not describe, so on an instance that wires only one direction \u2014 the normal shape for audio output or a worldsemi,ws2812-i2s LED strip \u2014 the other direction dereferences a NULL pointer instead of returning an error.\n\ni2s_trigger() is a Zephyr syscall, and z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only the device object and the presence of the trigger API pointer; the dir argument is passed to the driver unvalidated. On a build with CONFIG_USERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2s_trigger() call naming the unwired direction and cause a load from address 0 in kernel mode. Among the Espressif parts that carry this driver, userspace is available in-tree only on RISC-V SoCs with CONFIG_RISCV_PMP, and v4.4.0 is the first release where that is buildable: the ESP32-C6 HPCORE selects RISCV_PMP when it is not built for MCUboot. ESP32-C5 in v4.4.x carries the same PMP-region and userspace linker support but does not select RISCV_PMP by default. Espressif Xtensa targets do not support Zephyr userspace, and in a non-userspace build the bad direction can only come from in-kernel application code.\n\nThe impact is limited to availability: the access is a read at offset 0 of the missing stream structure, so there is no attacker-controlled offset, no write primitive and no information disclosure. With the default fatal-error handler the resulting exception halts the system, giving an unprivileged user-mode thread a system-wide denial of service. The fix adds the same pointer check the I2S_DIR_BOTH branch already performed and returns -ENOSYS for a direction the instance does not implement; the driver\u0027s other entry points (i2s_esp32_config_check(), i2s_esp32_config_get(), i2s_esp32_read(), i2s_esp32_write()) already guarded the pointers, and a static audit found no equivalent unguarded path.\n\nThe driver defect is older than the affected range. The unguarded dereference is present from v4.2.0 (reached through i2s_esp32_trigger_stream(), whose if (stream) guard tests the address of a struct member and is never false) and takes its present i2s_esp32_trigger_check() form in v4.3.0. No in-tree Espressif configuration before v4.4.0 can run a user-mode thread, so in v4.2.x and v4.3.x the direction argument can only come from trusted kernel code. Those releases carry the bug but are not listed as affected; the fix has also been merged to v4.3-branch as hardening."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-476",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:15:01.878Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/0d82dbbe72f154de32cc45021a9f59d9a737246b"
},
{
"name": "GHSA-5g9q-h8wq-rrf3",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-5g9q-h8wq-rrf3"
}
],
"title": "NULL pointer dereference in the ESP32 I2S driver when triggering an unsupported direction",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19737",
"datePublished": "2026-10-11T17:15:01.878Z",
"dateReserved": "2026-08-13T13:46:28.028Z",
"dateUpdated": "2026-10-16T15:46:16.400Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18418 (GCVE-0-2026-18418)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:15 – Updated: 2026-10-15 18:09
VLAI
EPSS
VEX
Title
Out-of-bounds read when the zbus proxy agent IPC backend logs a rejected peer frame's channel name
Summary
The zbus proxy agent IPC backend in subsys/zbus/proxy_agent/zbus_proxy_agent_ipc.c logged the channel name of a rejected inter-domain frame with a plain %s conversion. The frame type struct zbus_proxy_msg carries a fixed-size channel_name[] array as its last member, and nothing in the transport guarantees the array is NUL-terminated. The only code that verifies termination is zbus_proxy_agent_receive_cb() in subsys/zbus/proxy_agent/zbus_proxy_agent.c, which rejects the frame in precisely those cases — so the warning printed a non-terminated buffer exactly on the error paths where the name had been found invalid (or, for an invalid message_size, had not been inspected at all).
Any peer domain able to place a frame of sizeof(struct zbus_proxy_msg) bytes on the bound ipc_service endpoint can trigger it, by sending a frame with an out-of-range message_size or with channel_name[] containing no NUL byte. Reaching the code requires CONFIG_ZBUS_PROXY_AGENT_IPC and logging built at warning level or above (the default), and requires control over the firmware of the peer domain — typically a second core on the same SoC.
The resulting strlen() inside the log packager walks past the end of the frame object until it finds a zero byte. With the icmsg backend the frame lives in a stack buffer of the IPC work-queue thread, so bytes of that thread's stack are rendered into the log message; with the rpmsg backends the scan continues through the shared vring memory. Impact is bounded to disclosure of a small amount of adjacent memory into the receiving domain's log sink, plus a possible fatal fault if the scan leaves a mapped region; the log packager's own -ENOSPC bound prevents the overrun from becoming a write. The fix bounds the conversion with %.*s and MIN(msg->channel_name_len, sizeof(msg->channel_name)).
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-15 17:51 UTC
CWE
- CWE-125 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.4.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18418",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T17:51:25.324466Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T18:09:08.898Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/zbus/proxy_agent/zbus_proxy_agent_ipc.c"
],
"programRoutines": [
{
"name": "zbus_proxy_agent_ipc_recv_callback"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The zbus proxy agent IPC backend in subsys/zbus/proxy_agent/zbus_proxy_agent_ipc.c logged the channel name of a rejected inter-domain frame with a plain %s conversion. The frame type struct zbus_proxy_msg carries a fixed-size channel_name[] array as its last member, and nothing in the transport guarantees the array is NUL-terminated. The only code that verifies termination is zbus_proxy_agent_receive_cb() in subsys/zbus/proxy_agent/zbus_proxy_agent.c, which rejects the frame in precisely those cases \u2014 so the warning printed a non-terminated buffer exactly on the error paths where the name had been found invalid (or, for an invalid message_size, had not been inspected at all).\n\nAny peer domain able to place a frame of sizeof(struct zbus_proxy_msg) bytes on the bound ipc_service endpoint can trigger it, by sending a frame with an out-of-range message_size or with channel_name[] containing no NUL byte. Reaching the code requires CONFIG_ZBUS_PROXY_AGENT_IPC and logging built at warning level or above (the default), and requires control over the firmware of the peer domain \u2014 typically a second core on the same SoC.\n\nThe resulting strlen() inside the log packager walks past the end of the frame object until it finds a zero byte. With the icmsg backend the frame lives in a stack buffer of the IPC work-queue thread, so bytes of that thread\u0027s stack are rendered into the log message; with the rpmsg backends the scan continues through the shared vring memory. Impact is bounded to disclosure of a small amount of adjacent memory into the receiving domain\u0027s log sink, plus a possible fatal fault if the scan leaves a mapped region; the log packager\u0027s own -ENOSPC bound prevents the overrun from becoming a write. The fix bounds the conversion with %.*s and MIN(msg-\u003echannel_name_len, sizeof(msg-\u003echannel_name))."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 3.4,
"baseSeverity": "LOW",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:L",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:15:00.221Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/fc065f79a568a6c6cc14b89795bd60e5eabd6f02"
},
{
"name": "GHSA-48w8-fjhj-r9w8",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-48w8-fjhj-r9w8"
}
],
"title": "Out-of-bounds read when the zbus proxy agent IPC backend logs a rejected peer frame\u0027s channel name",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18418",
"datePublished": "2026-10-11T17:15:00.221Z",
"dateReserved": "2026-07-30T17:54:15.055Z",
"dateUpdated": "2026-10-15T18:09:08.898Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19736 (GCVE-0-2026-19736)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:14 – Updated: 2026-10-15 18:09
VLAI
EPSS
VEX
Title
Out-of-bounds write in the NXP MCUX TRNG entropy driver for non-word-multiple request lengths
Summary
The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNG_SW_HEALTH_TESTS variant, which always copies whole 32-bit words and draws entropy rounded up to a multiple of 128 bytes. Its "caller buffer is full" guard tests dataSize == 0, so a request whose length is not a multiple of four makes dataSize underflow past zero and the SDK keeps writing into the caller's buffer for the entire extraction: a 1-byte request results in 128 bytes written, and any non-word-multiple length overflows by up to 127 bytes.
entropy_get_entropy() is a syscall, and its verifier in drivers/entropy/entropy_handlers.c validates only the requested length via K_SYSCALL_MEMORY_WRITE(). With CONFIG_USERSPACE enabled, an unprivileged user-mode thread that has merely been granted the entropy device can therefore choose both the destination address and a length such as 1, and cause the kernel to write up to 127 bytes beyond the region it proved it owns. On these Cortex-M33 targets there is no MMU, so user partitions and kernel data share one SRAM and the overflow can land in adjacent kernel state. The same defect is reached from kernel mode by any caller requesting a non-word-multiple length, including getentropy() and, in builds where sys_csrand_get()/sys_rand_get() resolve to the hardware generator, sys_rand8_get() and sys_rand16_get().
Impact is memory corruption of up to 127 bytes immediately following the supplied buffer — typically the caller's stack in kernel-mode use, or memory outside the caller's partition when driven through the syscall. The overflow offset is fully determined by the requested length and is therefore deterministic, while the written content is uncontrolled TRNG output; the practical consequences range from crashes and unpredictable state corruption to opportunistic escalation when kernel bookkeeping such as object permission bitmaps is overwritten. The affected devices are those where the MCUX SDK enables TRNG_SW_HEALTH_TESTS (MIMXRT595S, MIMXRT555S, MIMXRT533S, MIMXRT685S, MIMXRT633S), on which the TRNG is the zephyr,entropy chosen node; other SoCs using this driver take the SDK path that clamps the copy size and are unaffected.
The fix routes any unaligned prefix and any sub-word tail through a local bounce word and hands the SDK only word-multiple sizes, so the SDK's word-granular writes can no longer pass the end of the caller's buffer.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-15 17:57 UTC
CWE
- CWE-787 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.3.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19736",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T17:57:42.294702Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T18:09:14.445Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/entropy/entropy_mcux_trng.c"
],
"programRoutines": [
{
"name": "entropy_get_entropy"
},
{
"name": "entropy_mcux_trng_get_entropy"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller\u0027s byte count straight to the vendor SDK routine TRNG_GetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNG_SW_HEALTH_TESTS variant, which always copies whole 32-bit words and draws entropy rounded up to a multiple of 128 bytes. Its \"caller buffer is full\" guard tests dataSize == 0, so a request whose length is not a multiple of four makes dataSize underflow past zero and the SDK keeps writing into the caller\u0027s buffer for the entire extraction: a 1-byte request results in 128 bytes written, and any non-word-multiple length overflows by up to 127 bytes.\n\nentropy_get_entropy() is a syscall, and its verifier in drivers/entropy/entropy_handlers.c validates only the requested length via K_SYSCALL_MEMORY_WRITE(). With CONFIG_USERSPACE enabled, an unprivileged user-mode thread that has merely been granted the entropy device can therefore choose both the destination address and a length such as 1, and cause the kernel to write up to 127 bytes beyond the region it proved it owns. On these Cortex-M33 targets there is no MMU, so user partitions and kernel data share one SRAM and the overflow can land in adjacent kernel state. The same defect is reached from kernel mode by any caller requesting a non-word-multiple length, including getentropy() and, in builds where sys_csrand_get()/sys_rand_get() resolve to the hardware generator, sys_rand8_get() and sys_rand16_get().\n\nImpact is memory corruption of up to 127 bytes immediately following the supplied buffer \u2014 typically the caller\u0027s stack in kernel-mode use, or memory outside the caller\u0027s partition when driven through the syscall. The overflow offset is fully determined by the requested length and is therefore deterministic, while the written content is uncontrolled TRNG output; the practical consequences range from crashes and unpredictable state corruption to opportunistic escalation when kernel bookkeeping such as object permission bitmaps is overwritten. The affected devices are those where the MCUX SDK enables TRNG_SW_HEALTH_TESTS (MIMXRT595S, MIMXRT555S, MIMXRT533S, MIMXRT685S, MIMXRT633S), on which the TRNG is the zephyr,entropy chosen node; other SoCs using this driver take the SDK path that clamps the copy size and are unaffected.\n\nThe fix routes any unaligned prefix and any sub-word tail through a local bounce word and hands the SDK only word-multiple sizes, so the SDK\u0027s word-granular writes can no longer pass the end of the caller\u0027s buffer."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:14:58.574Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/2c132efaf03a5d45aeaf7b0531c1107db7a36a3d"
},
{
"name": "GHSA-3f6q-3949-rqph",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-3f6q-3949-rqph"
}
],
"title": "Out-of-bounds write in the NXP MCUX TRNG entropy driver for non-word-multiple request lengths",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19736",
"datePublished": "2026-10-11T17:14:58.574Z",
"dateReserved": "2026-08-13T13:46:26.118Z",
"dateUpdated": "2026-10-15T18:09:14.445Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19735 (GCVE-0-2026-19735)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:14 – Updated: 2026-10-16 17:20
VLAI
EPSS
VEX
Title
Predictable TCP initial sequence numbers when the RFC 6528 secret key generation fails silently in the Zephyr TCP stack
Summary
The RFC 6528 initial-sequence-number implementation in subsys/net/ip/tcp.c derived every TCP ISN from SHA-256(unique_key || four-tuple) plus a uptime-derived offset, where unique_key is a 128-bit secret filled once by sys_csrand_get(). The return value of that call was discarded and the once guard was latched to true even when the call failed. Because sys_csrand_get() leaves the destination buffer untouched on failure (it deliberately propagates the entropy-driver error rather than filling the buffer), a single failed call left unique_key as its all-zero BSS content for the remainder of the boot, with no retry, no log message and no fallback.
A failure of the cryptographic random source is required to reach the weak state — for example -ENODEV/-EIO from the entropy driver in subsys/random/random_entropy_device.c (the in-tree comment notes that the hardware RNG "might still be gathering entropy during early boot situations"), or psa_generate_random() failing in subsys/random/random_psa.c when PSA crypto is not initialised or is backed by a Bluetooth-HCI entropy device that is not yet up. The first TCP connection is what triggers key generation, so a remote peer that reaches a listening port immediately after boot, or that can provoke a reboot, has indirect influence over whether generation coincides with that window. tcp_init_isn() is called for every passive open in tcp_conn_new() and every active open in net_tcp_connect(), so the poisoned key governs all TCP connections for that boot.
With an all-zero key the ISN becomes a public function of the connection four-tuple plus a device-wide time offset. An off-path attacker can compute the hash term offline for any four-tuple and recover the shared time offset from a single observed ISN, after which the ISN the device will pick for other four-tuples is predictable. That defeats exactly the protection RFC 6528 provides: blind TCP connection spoofing against peers that trust the source address, and blind data injection into or reset of connections whose four-tuple can be guessed. Devices whose entropy source never errors were never in the weak state.
The fix moves key generation into a single guarded helper that latches only on success, logs the error otherwise, and makes tcp_init_isn() fall back to sys_rand32_get() — the behaviour already used when CONFIG_NET_TCP_ISN_RFC6528 is disabled — instead of hashing with a known-constant key.
Severity
4.8 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-16 17:01 UTC
CWE
- CWE-330 - crypto
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.7.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19735",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-16T17:01:41.848775Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-16T17:20:06.564Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/net/ip/tcp.c"
],
"programRoutines": [
{
"name": "tcp_init_isn"
},
{
"name": "tcpv4_init_isn"
},
{
"name": "tcpv6_init_isn"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "3.7.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The RFC 6528 initial-sequence-number implementation in subsys/net/ip/tcp.c derived every TCP ISN from SHA-256(unique_key || four-tuple) plus a uptime-derived offset, where unique_key is a 128-bit secret filled once by sys_csrand_get(). The return value of that call was discarded and the once guard was latched to true even when the call failed. Because sys_csrand_get() leaves the destination buffer untouched on failure (it deliberately propagates the entropy-driver error rather than filling the buffer), a single failed call left unique_key as its all-zero BSS content for the remainder of the boot, with no retry, no log message and no fallback.\n\nA failure of the cryptographic random source is required to reach the weak state \u2014 for example -ENODEV/-EIO from the entropy driver in subsys/random/random_entropy_device.c (the in-tree comment notes that the hardware RNG \"might still be gathering entropy during early boot situations\"), or psa_generate_random() failing in subsys/random/random_psa.c when PSA crypto is not initialised or is backed by a Bluetooth-HCI entropy device that is not yet up. The first TCP connection is what triggers key generation, so a remote peer that reaches a listening port immediately after boot, or that can provoke a reboot, has indirect influence over whether generation coincides with that window. tcp_init_isn() is called for every passive open in tcp_conn_new() and every active open in net_tcp_connect(), so the poisoned key governs all TCP connections for that boot.\n\nWith an all-zero key the ISN becomes a public function of the connection four-tuple plus a device-wide time offset. An off-path attacker can compute the hash term offline for any four-tuple and recover the shared time offset from a single observed ISN, after which the ISN the device will pick for other four-tuples is predictable. That defeats exactly the protection RFC 6528 provides: blind TCP connection spoofing against peers that trust the source address, and blind data injection into or reset of connections whose four-tuple can be guessed. Devices whose entropy source never errors were never in the weak state.\n\nThe fix moves key generation into a single guarded helper that latches only on success, logs the error otherwise, and makes tcp_init_isn() fall back to sys_rand32_get() \u2014 the behaviour already used when CONFIG_NET_TCP_ISN_RFC6528 is disabled \u2014 instead of hashing with a known-constant key."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-330",
"description": "crypto",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:14:56.782Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/700888e3ecff8474f4fe7dfa8782b8869053222b"
},
{
"name": "GHSA-37mc-2q9v-fp64",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-37mc-2q9v-fp64"
}
],
"title": "Predictable TCP initial sequence numbers when the RFC 6528 secret key generation fails silently in the Zephyr TCP stack",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19735",
"datePublished": "2026-10-11T17:14:56.782Z",
"dateReserved": "2026-08-13T13:46:24.318Z",
"dateUpdated": "2026-10-16T17:20:06.564Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19577 (GCVE-0-2026-19577)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:14 – Updated: 2026-10-15 18:09
VLAI
EPSS
VEX
Title
Out-of-bounds read in IPv6 route forwarding when the nexthop neighbor has no link-layer address
Summary
net_route_ipv6_packet() in subsys/net/ip/route_ipv6.c resolved the nexthop's link-layer address with net_nbr_get_lladdr(nbr->idx) without first checking whether the neighbor cache entry actually had a linked link-layer address. An unresolved neighbor carries idx == NET_NBR_LLADDR_UNKNOWN (0xff), and net_nbr_get_lladdr() in subsys/net/ip/nbr.c performs no runtime bounds check beyond a NET_ASSERT, returning &net_neighbor_lladdr[255] — roughly 2.5 KB past the end of an array whose default size is CONFIG_NET_IPV6_MAX_NEIGHBORS (8). Because the returned pointer is never NULL, the following lladdr == NULL guard does not catch it.
The function is reached from ipv6_route_packet() in subsys/net/ip/ipv6.c for every received unicast IPv6 packet whose destination is not a local address on the receiving interface; CONFIG_NET_IPV6_ROUTE is enabled by default whenever the IPv6 neighbor cache is, so no router or forwarding configuration is needed. net_route_ipv6_get_info() returns the packet's destination itself as the nexthop when a neighbor cache entry for it exists, and the cache lookup does not skip INCOMPLETE entries. An unauthenticated attacker on the same link can therefore force the unresolved state — for example by eliciting traffic to a spoofed, non-existent neighbor address so that net_ipv6_send_ns() creates an INCOMPLETE entry, or by sending a Router Advertisement with no source link-layer address option, which creates a persistently unresolved router neighbor — and then send a packet addressed to that neighbor.
The result is an out-of-bounds read at a fixed index past the neighbor link-layer address array. On builds with CONFIG_ASSERT enabled the assertion fires and the device panics, giving a repeatable remote denial of service. With assertions disabled, the stale out-of-bounds struct net_linkaddr drives a memcmp() over an attacker-uninfluenced length and, when its len byte passes the NET_LINK_ADDR_MAX_LENGTH check, up to 8 bytes of unrelated static RAM are copied into the outgoing frame's destination link-layer address and transmitted on the link, disclosing them to any listener. There is no out-of-bounds write and the offset is not attacker-controlled, which bounds the impact.
Severity
7.1 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-15 17:51 UTC
CWE
- CWE-125 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
1.8.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19577",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T17:51:23.978223Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T18:09:20.629Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/net/ip/route.c",
"subsys/net/ip/route_ipv6.c"
],
"programRoutines": [
{
"name": "net_route_ipv6_packet"
},
{
"name": "net_route_packet"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "1.8.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "net_route_ipv6_packet() in subsys/net/ip/route_ipv6.c resolved the nexthop\u0027s link-layer address with net_nbr_get_lladdr(nbr-\u003eidx) without first checking whether the neighbor cache entry actually had a linked link-layer address. An unresolved neighbor carries idx == NET_NBR_LLADDR_UNKNOWN (0xff), and net_nbr_get_lladdr() in subsys/net/ip/nbr.c performs no runtime bounds check beyond a NET_ASSERT, returning \u0026net_neighbor_lladdr[255] \u2014 roughly 2.5 KB past the end of an array whose default size is CONFIG_NET_IPV6_MAX_NEIGHBORS (8). Because the returned pointer is never NULL, the following lladdr == NULL guard does not catch it.\n\nThe function is reached from ipv6_route_packet() in subsys/net/ip/ipv6.c for every received unicast IPv6 packet whose destination is not a local address on the receiving interface; CONFIG_NET_IPV6_ROUTE is enabled by default whenever the IPv6 neighbor cache is, so no router or forwarding configuration is needed. net_route_ipv6_get_info() returns the packet\u0027s destination itself as the nexthop when a neighbor cache entry for it exists, and the cache lookup does not skip INCOMPLETE entries. An unauthenticated attacker on the same link can therefore force the unresolved state \u2014 for example by eliciting traffic to a spoofed, non-existent neighbor address so that net_ipv6_send_ns() creates an INCOMPLETE entry, or by sending a Router Advertisement with no source link-layer address option, which creates a persistently unresolved router neighbor \u2014 and then send a packet addressed to that neighbor.\n\nThe result is an out-of-bounds read at a fixed index past the neighbor link-layer address array. On builds with CONFIG_ASSERT enabled the assertion fires and the device panics, giving a repeatable remote denial of service. With assertions disabled, the stale out-of-bounds struct net_linkaddr drives a memcmp() over an attacker-uninfluenced length and, when its len byte passes the NET_LINK_ADDR_MAX_LENGTH check, up to 8 bytes of unrelated static RAM are copied into the outgoing frame\u0027s destination link-layer address and transmitted on the link, disclosing them to any listener. There is no out-of-bounds write and the offset is not attacker-controlled, which bounds the impact."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.1,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:14:55.032Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/b0b0e8973d1967114adbb9ed1611d448b5a46519"
},
{
"name": "GHSA-vv76-4m89-95q5",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-vv76-4m89-95q5"
}
],
"title": "Out-of-bounds read in IPv6 route forwarding when the nexthop neighbor has no link-layer address",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19577",
"datePublished": "2026-10-11T17:14:55.032Z",
"dateReserved": "2026-08-11T19:57:38.944Z",
"dateUpdated": "2026-10-15T18:09:20.629Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19576 (GCVE-0-2026-19576)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:14 – Updated: 2026-10-15 18:09
VLAI
EPSS
VEX
Title
Stack out-of-bounds write in the Goodix GT911 touch controller driver from an unvalidated device-reported touch point count
Summary
The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller's status register and masks it with GT911_TOUCH_POINTS_MSK (0x0F), yielding a value of 0..15. In gt911_process() that value is used directly as the loop bound for filling point_reg[], a stack array sized to CONFIG_INPUT_GT911_MAX_TOUCH_POINTS, whose Kconfig range is 1..5 with a default of 1. No other check constrains the count; the driver relied only on a comment asserting that the controller had been programmed at init to report no more points than configured.
Each loop iteration issues an I2C read of eight bytes straight into point_reg[i], so a controller that reports more points than the array holds causes up to 112 bytes of peer-supplied data to be written past the end of the array, over the stack frame of gt911_process() in the system workqueue thread. Two further loops then read out of bounds from the same array. Triggering it requires control of, or the ability to substitute, the I2C touch controller — plausible on the many supported boards where the GT9xx panel is a pluggable display module or shield rather than an on-PCB part; a spoofed device need only answer the init probes with a supported product ID and a checksum-valid config blob. The same overflow can also occur non-adversarially, with a GT9271-class panel that ignores the driver's touch-count programming and reports up to ten points, or with bus corruption of the single status byte.
The impact is an out-of-bounds stack write with fully attacker-chosen content executing at kernel privilege, i.e. potential control-flow hijack on the host MCU, in addition to out-of-bounds reads and crashes. The attack vector is physical/local hardware access only; there is no network, USB, or syscall path to the defect. The fix clamps the reported count with min() against CONFIG_INPUT_GT911_MAX_TOUCH_POINTS before any array indexing.
Severity
6.8 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-15 17:57 UTC
CWE
- CWE-787 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.0.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19576",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T17:57:40.802963Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T18:09:27.588Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/input/input_gt911.c"
],
"programRoutines": [
{
"name": "gt911_process"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "4.0.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller\u0027s status register and masks it with GT911_TOUCH_POINTS_MSK (0x0F), yielding a value of 0..15. In gt911_process() that value is used directly as the loop bound for filling point_reg[], a stack array sized to CONFIG_INPUT_GT911_MAX_TOUCH_POINTS, whose Kconfig range is 1..5 with a default of 1. No other check constrains the count; the driver relied only on a comment asserting that the controller had been programmed at init to report no more points than configured.\n\nEach loop iteration issues an I2C read of eight bytes straight into point_reg[i], so a controller that reports more points than the array holds causes up to 112 bytes of peer-supplied data to be written past the end of the array, over the stack frame of gt911_process() in the system workqueue thread. Two further loops then read out of bounds from the same array. Triggering it requires control of, or the ability to substitute, the I2C touch controller \u2014 plausible on the many supported boards where the GT9xx panel is a pluggable display module or shield rather than an on-PCB part; a spoofed device need only answer the init probes with a supported product ID and a checksum-valid config blob. The same overflow can also occur non-adversarially, with a GT9271-class panel that ignores the driver\u0027s touch-count programming and reports up to ten points, or with bus corruption of the single status byte.\n\nThe impact is an out-of-bounds stack write with fully attacker-chosen content executing at kernel privilege, i.e. potential control-flow hijack on the host MCU, in addition to out-of-bounds reads and crashes. The attack vector is physical/local hardware access only; there is no network, USB, or syscall path to the defect. The fix clamps the reported count with min() against CONFIG_INPUT_GT911_MAX_TOUCH_POINTS before any array indexing."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.8,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:14:53.339Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/42b52d571eb2113012c135276693042fd372fdea"
},
{
"name": "GHSA-p7qh-fvwx-f7vr",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-p7qh-fvwx-f7vr"
}
],
"title": "Stack out-of-bounds write in the Goodix GT911 touch controller driver from an unvalidated device-reported touch point count",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19576",
"datePublished": "2026-10-11T17:14:53.339Z",
"dateReserved": "2026-08-11T19:56:48.396Z",
"dateUpdated": "2026-10-15T18:09:27.588Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19669 (GCVE-0-2026-19669)
Vulnerability from cvelistv5 – Published: 2026-10-11 17:14 – Updated: 2026-10-15 18:09
VLAI
EPSS
VEX
Title
Unbounded variable-length array in fuel gauge syscall verifiers allows kernel stack overflow from user mode
Summary
The user-mode syscall verifiers z_vrfy_fuel_gauge_get_props() and z_vrfy_fuel_gauge_set_props() in drivers/fuel_gauge/fuel_gauge_syscall_handlers.c declared two variable-length arrays, union fuel_gauge_prop_val k_vals[len] and fuel_gauge_prop_t k_props[len], sized directly by the caller-supplied len argument. len is an unvalidated size_t taken straight from the syscall ABI, and the VLAs were allocated before any check at all — including before the K_SYSCALL_DRIVER_FUEL_GAUGE() object-permission check. The subsequent k_usermode_from_copy() calls validated only that the user source buffer was readable; the kernel destination was never bounds-checked, since it was sized by the same attacker-chosen len.
Any thread running in user mode with CONFIG_USERSPACE enabled can invoke fuel_gauge_get_props() or fuel_gauge_set_props() with a large len. This first displaces the supervisor stack pointer by an arbitrary attacker-chosen amount — Zephyr does not build with stack-clash probing, so the displacement itself does not fault, and the nested calls made by the verifier then write frames below the privileged stack. If the caller has been granted access to a fuel-gauge device object, the memcpy inside k_usermode_from_copy() additionally writes len * sizeof(union fuel_gauge_prop_val) bytes of fully attacker-controlled data starting well below the stack base. CONFIG_PRIVILEGED_STACK_SIZE defaults to 1024 bytes, so a len of roughly 170 already exhausts it.
The result is an out-of-bounds write in supervisor mode with attacker-controlled length and, on the permitted path, attacker-controlled content — a break out of the user-mode sandbox into kernel memory, leading to kernel code execution or a system crash. A stack guard region does not contain it, because the copy begins below the guard and walks upward, corrupting unprotected memory before the guard is reached. The fix removes the kernel-side copies entirely and validates the caller's arrays in place with K_SYSCALL_MEMORY_ARRAY_READ() / K_SYSCALL_MEMORY_ARRAY_WRITE(), which also handle the len * size multiplication overflow; this is safe because neither fuel_gauge_prop_t nor union fuel_gauge_prop_val contains embedded pointers.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-15 17:57 UTC
CWE
- CWE-787 - memory-safety
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.4.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19669",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T17:57:39.407044Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T18:09:35.759Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/fuel_gauge/fuel_gauge_syscall_handlers.c"
],
"programRoutines": [
{
"name": "z_vrfy_fuel_gauge_get_props"
},
{
"name": "z_vrfy_fuel_gauge_set_props"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The user-mode syscall verifiers z_vrfy_fuel_gauge_get_props() and z_vrfy_fuel_gauge_set_props() in drivers/fuel_gauge/fuel_gauge_syscall_handlers.c declared two variable-length arrays, union fuel_gauge_prop_val k_vals[len] and fuel_gauge_prop_t k_props[len], sized directly by the caller-supplied len argument. len is an unvalidated size_t taken straight from the syscall ABI, and the VLAs were allocated before any check at all \u2014 including before the K_SYSCALL_DRIVER_FUEL_GAUGE() object-permission check. The subsequent k_usermode_from_copy() calls validated only that the user source buffer was readable; the kernel destination was never bounds-checked, since it was sized by the same attacker-chosen len.\n\nAny thread running in user mode with CONFIG_USERSPACE enabled can invoke fuel_gauge_get_props() or fuel_gauge_set_props() with a large len. This first displaces the supervisor stack pointer by an arbitrary attacker-chosen amount \u2014 Zephyr does not build with stack-clash probing, so the displacement itself does not fault, and the nested calls made by the verifier then write frames below the privileged stack. If the caller has been granted access to a fuel-gauge device object, the memcpy inside k_usermode_from_copy() additionally writes len * sizeof(union fuel_gauge_prop_val) bytes of fully attacker-controlled data starting well below the stack base. CONFIG_PRIVILEGED_STACK_SIZE defaults to 1024 bytes, so a len of roughly 170 already exhausts it.\n\nThe result is an out-of-bounds write in supervisor mode with attacker-controlled length and, on the permitted path, attacker-controlled content \u2014 a break out of the user-mode sandbox into kernel memory, leading to kernel code execution or a system crash. A stack guard region does not contain it, because the copy begins below the guard and walks upward, corrupting unprotected memory before the guard is reached. The fix removes the kernel-side copies entirely and validates the caller\u0027s arrays in place with K_SYSCALL_MEMORY_ARRAY_READ() / K_SYSCALL_MEMORY_ARRAY_WRITE(), which also handle the len * size multiplication overflow; this is safe because neither fuel_gauge_prop_t nor union fuel_gauge_prop_val contains embedded pointers."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-11T17:14:51.720Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/0d65ce46dda0626164503c50f37e6e1f59d310a9"
},
{
"name": "GHSA-6ghg-cmrw-8gw5",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6ghg-cmrw-8gw5"
}
],
"title": "Unbounded variable-length array in fuel gauge syscall verifiers allows kernel stack overflow from user mode",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19669",
"datePublished": "2026-10-11T17:14:51.720Z",
"dateReserved": "2026-08-12T20:43:46.670Z",
"dateUpdated": "2026-10-15T18:09:35.759Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19575 (GCVE-0-2026-19575)
Vulnerability from cvelistv5 – Published: 2026-10-09 07:16 – Updated: 2026-10-09 17:54
VLAI
EPSS
VEX
Title
Type confusion in the device_deinit system call allows user-mode threads to execute arbitrary kernel code
Summary
The user-mode verification handler for the device_deinit() system call, z_vrfy_device_deinit() in kernel/device.c, validated its dev argument with K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). k_object_validate() short-circuits its type comparison when the requested type is K_OBJ_ANY, so the check reduced to "this pointer is the base address of some kernel object the calling thread has been granted" — the object's actual type was never compared, and K_SYSCALL_OBJ_INIT also skips the initialization-state check. The sibling handlers z_vrfy_device_init() and z_vrfy_device_is_ready() already used K_OBJ_DRIVER_ANY and were unaffected.
A thread running in user mode can therefore pass any kernel object it holds permission on — most usefully a thread stack object obtained from the k_thread_stack_alloc() syscall or a statically defined K_THREAD_STACK it was granted in order to spawn a child user thread — whose backing memory is writable from user mode. z_impl_device_deinit() then interprets those attacker-written bytes as a struct device: it dereferences the state pointer read out of the object, calls the function pointer read out of ops.deinit, and on success writes through state again. The result is an indirect call to an arbitrary address executed in supervisor mode, plus an arbitrary kernel read and a single-byte kernel write.
Exploitation gives a local unprivileged thread full kernel code execution, defeating the CONFIG_USERSPACE isolation boundary entirely; a less precise attempt yields a supervisor-mode fault and a system crash. The defect is only reachable in builds that enable both CONFIG_USERSPACE and CONFIG_DEVICE_DEINIT_SUPPORT — with de-initialization support disabled, z_impl_device_deinit() returns -ENOTSUP without ever dereferencing the pointer. In v4.2.x and v4.3.x, CONFIG_DEVICE_DEINIT_SUPPORT defaulted to y, so every CONFIG_USERSPACE build of those releases is exposed unless the option was explicitly turned off. From v4.4.0 the option is opt-in (no default, and not selected by any in-tree subsystem), so a v4.4.x build is exposed only if it enables the option explicitly. The v4.2 line is no longer maintained and receives no backport.
The fix changes the object check to K_OBJ_DRIVER_ANY, which constrains the argument to the build-generated driver object type range (K_OBJ_DRIVER_FIRST..K_OBJ_DRIVER_LAST) — the real struct device instances placed by the linker — so the state and ops.deinit fields are once again kernel-controlled.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-09 17:53 UTC
CWE
- CWE-843 - memory-safety
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.2.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19575",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-09T17:53:21.684305Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T17:54:02.591Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"kernel/device.c"
],
"programRoutines": [
{
"name": "z_impl_device_deinit"
},
{
"name": "z_vrfy_device_deinit"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "4.2.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The user-mode verification handler for the device_deinit() system call, z_vrfy_device_deinit() in kernel/device.c, validated its dev argument with K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). k_object_validate() short-circuits its type comparison when the requested type is K_OBJ_ANY, so the check reduced to \"this pointer is the base address of some kernel object the calling thread has been granted\" \u2014 the object\u0027s actual type was never compared, and K_SYSCALL_OBJ_INIT also skips the initialization-state check. The sibling handlers z_vrfy_device_init() and z_vrfy_device_is_ready() already used K_OBJ_DRIVER_ANY and were unaffected.\n\nA thread running in user mode can therefore pass any kernel object it holds permission on \u2014 most usefully a thread stack object obtained from the k_thread_stack_alloc() syscall or a statically defined K_THREAD_STACK it was granted in order to spawn a child user thread \u2014 whose backing memory is writable from user mode. z_impl_device_deinit() then interprets those attacker-written bytes as a struct device: it dereferences the state pointer read out of the object, calls the function pointer read out of ops.deinit, and on success writes through state again. The result is an indirect call to an arbitrary address executed in supervisor mode, plus an arbitrary kernel read and a single-byte kernel write.\n\nExploitation gives a local unprivileged thread full kernel code execution, defeating the CONFIG_USERSPACE isolation boundary entirely; a less precise attempt yields a supervisor-mode fault and a system crash. The defect is only reachable in builds that enable both CONFIG_USERSPACE and CONFIG_DEVICE_DEINIT_SUPPORT \u2014 with de-initialization support disabled, z_impl_device_deinit() returns -ENOTSUP without ever dereferencing the pointer. In v4.2.x and v4.3.x, CONFIG_DEVICE_DEINIT_SUPPORT defaulted to y, so every CONFIG_USERSPACE build of those releases is exposed unless the option was explicitly turned off. From v4.4.0 the option is opt-in (no default, and not selected by any in-tree subsystem), so a v4.4.x build is exposed only if it enables the option explicitly. The v4.2 line is no longer maintained and receives no backport.\n\nThe fix changes the object check to K_OBJ_DRIVER_ANY, which constrains the argument to the build-generated driver object type range (K_OBJ_DRIVER_FIRST..K_OBJ_DRIVER_LAST) \u2014 the real struct device instances placed by the linker \u2014 so the state and ops.deinit fields are once again kernel-controlled."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-843",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T07:16:47.995Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/1036694889ab33996db41b4141ddf66aa786d267"
},
{
"name": "GHSA-j9m4-fr5f-49wm",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j9m4-fr5f-49wm"
}
],
"title": "Type confusion in the device_deinit system call allows user-mode threads to execute arbitrary kernel code",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19575",
"datePublished": "2026-10-09T07:16:47.995Z",
"dateReserved": "2026-08-11T19:47:44.428Z",
"dateUpdated": "2026-10-09T17:54:02.591Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19569 (GCVE-0-2026-19569)
Vulnerability from cvelistv5 – Published: 2026-10-09 07:16 – Updated: 2026-10-09 17:55
VLAI
EPSS
VEX
Title
Integer overflow in dynamic kernel object allocation allows user-mode threads to corrupt the kernel heap
Summary
dynamic_object_create() in kernel/userspace/userspace.c computed the backing allocation for a dynamically allocated kernel object as obj_size_get(otype) + size, and for thread stack elements as STACK_ELEMENT_DATA_SIZE(size) (a round-up plus fixed overhead), without checking either expression for unsigned wrap-around. A size close to SIZE_MAX makes the computed total wrap to a very small value, so the heap chunk handed out is a few bytes while the object descriptor is still tagged with the full requested type and registered in the kernel object table.
The size argument reaches that arithmetic directly from user mode. k_object_alloc_size() is declared __syscall in include/zephyr/sys/kobject.h, its verifier z_vrfy_k_object_alloc_size() in kernel/userspace/userspace_handler.c is a bare pass-through, and z_object_alloc() only range-checks otype — nothing bounds size. The stack-element branch is additionally reachable through the k_thread_stack_alloc() syscall via kernel/dynamic.c. Because subsequent kernel-object validation checks only the object's type and initialization state, the undersized handle passes K_SYSCALL_OBJ_INIT()/K_SYSCALL_OBJ_NEVER_INIT(), and the matching init syscall (for example k_mutex_init(), k_sem_init(), or k_thread_create()) then writes a complete object over the truncated allocation.
An unprivileged user-mode thread can therefore trigger a supervisor-mode out-of-bounds write into the kernel resource-pool heap, of a size and content it substantially controls, corrupting sys_heap chunk metadata and adjacent kernel objects. Under CONFIG_GEN_PRIV_STACKS the thread-stack branch additionally stores an attacker-influenced wild pointer as a user thread's privileged stack base. The practical result is escape from the CONFIG_USERSPACE sandbox — kernel-level code execution or at minimum kernel memory corruption and system compromise.
Exploitation requires CONFIG_USERSPACE together with CONFIG_DYNAMIC_OBJECTS (also selected by CONFIG_DYNAMIC_THREAD under userspace), and a calling thread with an assigned resource pool. The fix rejects both overflowing computations and frees the partially built descriptor.
Severity
8.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-09 17:54 UTC
CWE
- CWE-190 - integer-overflow
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.5.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19569",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-09T17:54:39.210506Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T17:55:18.376Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"kernel/userspace/userspace.c"
],
"programRoutines": [
{
"name": "dynamic_object_create"
},
{
"name": "z_impl_k_object_alloc_size"
},
{
"name": "z_impl_k_thread_stack_alloc"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "3.5.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "dynamic_object_create() in kernel/userspace/userspace.c computed the backing allocation for a dynamically allocated kernel object as obj_size_get(otype) + size, and for thread stack elements as STACK_ELEMENT_DATA_SIZE(size) (a round-up plus fixed overhead), without checking either expression for unsigned wrap-around. A size close to SIZE_MAX makes the computed total wrap to a very small value, so the heap chunk handed out is a few bytes while the object descriptor is still tagged with the full requested type and registered in the kernel object table.\n\nThe size argument reaches that arithmetic directly from user mode. k_object_alloc_size() is declared __syscall in include/zephyr/sys/kobject.h, its verifier z_vrfy_k_object_alloc_size() in kernel/userspace/userspace_handler.c is a bare pass-through, and z_object_alloc() only range-checks otype \u2014 nothing bounds size. The stack-element branch is additionally reachable through the k_thread_stack_alloc() syscall via kernel/dynamic.c. Because subsequent kernel-object validation checks only the object\u0027s type and initialization state, the undersized handle passes K_SYSCALL_OBJ_INIT()/K_SYSCALL_OBJ_NEVER_INIT(), and the matching init syscall (for example k_mutex_init(), k_sem_init(), or k_thread_create()) then writes a complete object over the truncated allocation.\n\nAn unprivileged user-mode thread can therefore trigger a supervisor-mode out-of-bounds write into the kernel resource-pool heap, of a size and content it substantially controls, corrupting sys_heap chunk metadata and adjacent kernel objects. Under CONFIG_GEN_PRIV_STACKS the thread-stack branch additionally stores an attacker-influenced wild pointer as a user thread\u0027s privileged stack base. The practical result is escape from the CONFIG_USERSPACE sandbox \u2014 kernel-level code execution or at minimum kernel memory corruption and system compromise.\n\nExploitation requires CONFIG_USERSPACE together with CONFIG_DYNAMIC_OBJECTS (also selected by CONFIG_DYNAMIC_THREAD under userspace), and a calling thread with an assigned resource pool. The fix rejects both overflowing computations and frees the partially built descriptor."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-190",
"description": "integer-overflow",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T07:16:45.305Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/85c1c4c21945d9b8fcef03216f1ccb2b27794e3d"
},
{
"name": "GHSA-fg8c-9fhq-q7hv",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-fg8c-9fhq-q7hv"
}
],
"title": "Integer overflow in dynamic kernel object allocation allows user-mode threads to corrupt the kernel heap",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19569",
"datePublished": "2026-10-09T07:16:45.305Z",
"dateReserved": "2026-08-11T19:13:49.614Z",
"dateUpdated": "2026-10-09T17:55:18.376Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19574 (GCVE-0-2026-19574)
Vulnerability from cvelistv5 – Published: 2026-10-09 07:16 – Updated: 2026-10-09 17:56
VLAI
EPSS
VEX
Title
ARM64 MMU can assign an in-use ASID to a new memory domain, breaking user-mode memory isolation
Summary
The ARM64 MMU back-end allocated address space identifiers (ASIDs) for memory domains with a bare round-robin counter in arch_mem_domain_init() (arch/arm64/core/mmu.c). VM_ASID_BITS is 8, so only 255 ASIDs exist; once the counter wrapped, arch_mem_domain_init() could hand an ASID to a new domain while a still-live domain held the same one. Domain-private mappings are installed non-global (MT_NG), so the ASID is the only tag separating one domain's cached translations from another's in the TLB.
The context-switch path in z_arm64_swap_ptables() only flushes the TLB when the outgoing and incoming domains carry the same ASID, which does not cover a duplicate reached through a third domain: for domains A and C sharing an ASID and an unrelated domain B, the schedule A -> B -> C never takes the flush branch, so the ASID-tagged entries A populated remain resident while C runs. Under SMP two live domains sharing an ASID can additionally be resident on two CPUs at once, which the architecture does not allow for distinct translation-table sets.
Triggering the wrap requires a CONFIG_USERSPACE application on ARM64 that creates more than 255 memory domains over its lifetime; k_mem_domain_init() and k_mem_domain_deinit() are supervisor-only APIs and are not exposed as syscalls, so an unprivileged thread cannot drive the counter directly. Once two live domains alias, however, a user-mode thread in one domain can read and write memory belonging to the other domain's partitions and thread stacks with that domain's permissions, defeating the memory-domain isolation boundary.
The fix scans the live domain_list before assigning an ASID, advances the round-robin counter past ASIDs already in use, and returns -ENOMEM when all are taken, so domain creation fails closed instead of silently aliasing.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-09 17:56 UTC
CWE
- CWE-284 - auth
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.3.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19574",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-09T17:56:13.062546Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T17:56:48.909Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"arch/arm64/core/mmu.c"
],
"programRoutines": [
{
"name": "arch_mem_domain_init"
},
{
"name": "k_mem_domain_init"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "3.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The ARM64 MMU back-end allocated address space identifiers (ASIDs) for memory domains with a bare round-robin counter in arch_mem_domain_init() (arch/arm64/core/mmu.c). VM_ASID_BITS is 8, so only 255 ASIDs exist; once the counter wrapped, arch_mem_domain_init() could hand an ASID to a new domain while a still-live domain held the same one. Domain-private mappings are installed non-global (MT_NG), so the ASID is the only tag separating one domain\u0027s cached translations from another\u0027s in the TLB.\n\nThe context-switch path in z_arm64_swap_ptables() only flushes the TLB when the outgoing and incoming domains carry the same ASID, which does not cover a duplicate reached through a third domain: for domains A and C sharing an ASID and an unrelated domain B, the schedule A -\u003e B -\u003e C never takes the flush branch, so the ASID-tagged entries A populated remain resident while C runs. Under SMP two live domains sharing an ASID can additionally be resident on two CPUs at once, which the architecture does not allow for distinct translation-table sets.\n\nTriggering the wrap requires a CONFIG_USERSPACE application on ARM64 that creates more than 255 memory domains over its lifetime; k_mem_domain_init() and k_mem_domain_deinit() are supervisor-only APIs and are not exposed as syscalls, so an unprivileged thread cannot drive the counter directly. Once two live domains alias, however, a user-mode thread in one domain can read and write memory belonging to the other domain\u0027s partitions and thread stacks with that domain\u0027s permissions, defeating the memory-domain isolation boundary.\n\nThe fix scans the live domain_list before assigning an ASID, advances the round-robin counter past ASIDs already in use, and returns -ENOMEM when all are taken, so domain creation fails closed instead of silently aliasing."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-284",
"description": "auth",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T07:16:43.058Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/805054b8ed89dd5441fbca36b3cd3be7e4fb4100"
},
{
"name": "GHSA-923h-8c2j-pcm5",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-923h-8c2j-pcm5"
}
],
"title": "ARM64 MMU can assign an in-use ASID to a new memory domain, breaking user-mode memory isolation",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19574",
"datePublished": "2026-10-09T07:16:43.058Z",
"dateReserved": "2026-08-11T19:47:42.367Z",
"dateUpdated": "2026-10-09T17:56:48.909Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19571 (GCVE-0-2026-19571)
Vulnerability from cvelistv5 – Published: 2026-10-09 07:16 – Updated: 2026-10-09 17:57
VLAI
EPSS
VEX
Title
Race condition in ITE IT8xxx2 SHI host-command backend lets a second SPI request write an unvalidated length into the in-flight request buffer
Summary
The ITE IT8xxx2 SHI host-command backend (subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c) copied the 8-byte host-command request header from the SPI Rx FIFO directly into the shared receive buffer data->in_msg and only afterwards checked the protocol version and the derived packet length. The interrupt handler also accepted a chip-select assertion and an Rx-valid-length (RVLI) interrupt in any driver state other than SHI_STATE_DISABLED, so a new header could be parsed while the host-command thread was still processing the previous request out of the very same buffer.
The host processor is the SPI controller and drives both chip select and the clock. After sending a well-formed request it can immediately de-assert chip select — which returns the driver to the ready state and re-enables the FIFO — and start a second transaction carrying a header with data_len = 0xFFFF. Those eight bytes are written into in_msg before the oversized length is rejected, so they land in a buffer whose contents verify_rx() in subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c has already validated. If this lands in the window before the host-command thread executes args.input_buf_size = rx_header->data_len, the framework hands the registered command handler a 65535-byte input length over a 256-byte buffer.
The result is an out-of-bounds read of up to roughly 64 KiB beyond the request buffer: command handlers that copy or echo input_buf_size bytes disclose adjacent embedded-controller memory back to the host or overflow the response buffer, and a read past the end of SRAM faults the controller. The same race also allows cmd_id and cmd_ver to be swapped after checksum verification and after handler lookup. Exploitation requires the ability to drive the inter-processor SHI bus (a compromised host OS or physical access to the SPI lines) and winning a timing race, which the SPI controller can retry indefinitely.
The fix parses the header into a local struct ec_host_cmd_request_header and copies it into in_msg only after the length has been bounded by sizeof(data->in_msg), and ignores chip-select and RVLI interrupts outside SHI_STATE_READY_TO_RECV/SHI_STATE_RECEIVING. A residual, bounded race remains: an end-of-transaction interrupt still resets the state to ready while the host-command thread owns the buffer, so a valid second request can still overwrite the in-flight request's contents, unlike the NPCX backend which parks in SHI_STATE_CNL_RESP_NOT_RDY while the buffer is in use.
Severity
6.7 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-09 17:57 UTC
CWE
- CWE-362 - race
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.3.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19571",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-09T17:57:11.124067Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T17:57:42.905Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c"
],
"programRoutines": [
{
"name": "shi_ite_cs_callback"
},
{
"name": "shi_ite_int_handler"
},
{
"name": "shi_ite_parse_header"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The ITE IT8xxx2 SHI host-command backend (subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c) copied the 8-byte host-command request header from the SPI Rx FIFO directly into the shared receive buffer data-\u003ein_msg and only afterwards checked the protocol version and the derived packet length. The interrupt handler also accepted a chip-select assertion and an Rx-valid-length (RVLI) interrupt in any driver state other than SHI_STATE_DISABLED, so a new header could be parsed while the host-command thread was still processing the previous request out of the very same buffer.\n\nThe host processor is the SPI controller and drives both chip select and the clock. After sending a well-formed request it can immediately de-assert chip select \u2014 which returns the driver to the ready state and re-enables the FIFO \u2014 and start a second transaction carrying a header with data_len = 0xFFFF. Those eight bytes are written into in_msg before the oversized length is rejected, so they land in a buffer whose contents verify_rx() in subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c has already validated. If this lands in the window before the host-command thread executes args.input_buf_size = rx_header-\u003edata_len, the framework hands the registered command handler a 65535-byte input length over a 256-byte buffer.\n\nThe result is an out-of-bounds read of up to roughly 64 KiB beyond the request buffer: command handlers that copy or echo input_buf_size bytes disclose adjacent embedded-controller memory back to the host or overflow the response buffer, and a read past the end of SRAM faults the controller. The same race also allows cmd_id and cmd_ver to be swapped after checksum verification and after handler lookup. Exploitation requires the ability to drive the inter-processor SHI bus (a compromised host OS or physical access to the SPI lines) and winning a timing race, which the SPI controller can retry indefinitely.\n\nThe fix parses the header into a local struct ec_host_cmd_request_header and copies it into in_msg only after the length has been bounded by sizeof(data-\u003ein_msg), and ignores chip-select and RVLI interrupts outside SHI_STATE_READY_TO_RECV/SHI_STATE_RECEIVING. A residual, bounded race remains: an end-of-transaction interrupt still resets the state to ready while the host-command thread owns the buffer, so a valid second request can still overwrite the in-flight request\u0027s contents, unlike the NPCX backend which parks in SHI_STATE_CNL_RESP_NOT_RDY while the buffer is in use."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.7,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-362",
"description": "race",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T07:16:40.717Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/0636e65c825e810ad97f154606365870152d402f"
},
{
"name": "GHSA-4x98-6536-cwjv",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4x98-6536-cwjv"
}
],
"title": "Race condition in ITE IT8xxx2 SHI host-command backend lets a second SPI request write an unvalidated length into the in-flight request buffer",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19571",
"datePublished": "2026-10-09T07:16:40.717Z",
"dateReserved": "2026-08-11T19:15:07.946Z",
"dateUpdated": "2026-10-09T17:57:42.905Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19570 (GCVE-0-2026-19570)
Vulnerability from cvelistv5 – Published: 2026-10-09 07:16 – Updated: 2026-10-09 17:58
VLAI
EPSS
VEX
Title
Out-of-bounds write in LE Audio Broadcast Sink when copying BASE subgroup metadata into the BASS receive state
Summary
The LE Audio Broadcast Sink in subsys/bluetooth/audio/bap_broadcast_sink.c copies subgroup metadata from a received Basic Audio Announcement (BASE) into the static Broadcast Audio Scan Service parameter structure mod_src_param without any bounds check. In base_subgroup_meta_cb() the destination element was selected as mod_src_param.subgroups[mod_src_param.num_subgroups] with no test against ARRAY_SIZE(mod_src_param.subgroups) (sized by CONFIG_BT_BAP_BASS_MAX_SUBGROUPS, default 1), and the metadata was copied with memcpy() using the raw on-air length returned by bt_bap_base_get_subgroup_codec_meta() into a metadata array sized by CONFIG_BT_AUDIO_CODEC_CFG_MAX_METADATA_SIZE (default 4). The BASE validator bt_bap_base_get_base_from_ad() only checks structural consistency and permits up to ~24 subgroups and metadata LTVs of ~240 octets.
The defect is reached from the periodic advertising receive callback: pa_recv() → bt_data_parse() → pa_decode_base() → update_recv_state_base() → bt_bap_base_foreach_subgroup() → base_subgroup_meta_cb(). Every broadcast sink registers a scan-delegator receive state at creation (bt_bap_broadcast_sink_create() calls broadcast_sink_add_src()), and CONFIG_BT_BAP_BROADCAST_SINK depends on CONFIG_BT_BAP_SCAN_DELEGATOR, so the path is active in every broadcast-sink build once the device is periodic-advertising-synced. An attacker in radio range who operates a broadcast source the device syncs to — or who impersonates the advertiser address and SID of one already in use, periodic advertising data being unauthenticated — can change the BASE at will; each new BASE is re-parsed.
A crafted BASE therefore writes attacker-chosen bytes past the end of a fixed static object in .bss: up to roughly 236 bytes for an oversized metadata LTV, plus whole struct bt_bap_bass_subgroup records for each subgroup beyond CONFIG_BT_BAP_BASS_MAX_SUBGROUPS. This is memory corruption of adjacent Bluetooth-audio state reachable with no pairing, bonding or GATT connection, with a potential for remote code execution in the Bluetooth RX thread; in addition, the unvalidated metadata_len is forwarded to bt_bap_scan_delegator_mod_src(), which neither clamps it nor rejects it, leading to a further copy into the receive state and to out-of-bounds memory being disclosed in the BASS receive-state notification sent to a connected Broadcast Assistant.
The fix rejects a BASE carrying more subgroups than the receive state can hold (discarding the update entirely) and omits metadata that does not fit rather than copying it, and additionally honours the previously-ignored error return of the subgroup decode pass.
Severity
8.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-09 17:58 UTC
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.6.0 , ≤ 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19570",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-09T17:58:11.396130Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T17:58:32.024Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/audio/bap_broadcast_sink.c"
],
"programRoutines": [
{
"name": "base_subgroup_meta_cb"
},
{
"name": "update_recv_state_base_copy_meta"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThanOrEqual": "4.4.2",
"status": "affected",
"version": "3.6.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The LE Audio Broadcast Sink in subsys/bluetooth/audio/bap_broadcast_sink.c copies subgroup metadata from a received Basic Audio Announcement (BASE) into the static Broadcast Audio Scan Service parameter structure mod_src_param without any bounds check. In base_subgroup_meta_cb() the destination element was selected as mod_src_param.subgroups[mod_src_param.num_subgroups] with no test against ARRAY_SIZE(mod_src_param.subgroups) (sized by CONFIG_BT_BAP_BASS_MAX_SUBGROUPS, default 1), and the metadata was copied with memcpy() using the raw on-air length returned by bt_bap_base_get_subgroup_codec_meta() into a metadata array sized by CONFIG_BT_AUDIO_CODEC_CFG_MAX_METADATA_SIZE (default 4). The BASE validator bt_bap_base_get_base_from_ad() only checks structural consistency and permits up to ~24 subgroups and metadata LTVs of ~240 octets.\n\nThe defect is reached from the periodic advertising receive callback: pa_recv() \u2192 bt_data_parse() \u2192 pa_decode_base() \u2192 update_recv_state_base() \u2192 bt_bap_base_foreach_subgroup() \u2192 base_subgroup_meta_cb(). Every broadcast sink registers a scan-delegator receive state at creation (bt_bap_broadcast_sink_create() calls broadcast_sink_add_src()), and CONFIG_BT_BAP_BROADCAST_SINK depends on CONFIG_BT_BAP_SCAN_DELEGATOR, so the path is active in every broadcast-sink build once the device is periodic-advertising-synced. An attacker in radio range who operates a broadcast source the device syncs to \u2014 or who impersonates the advertiser address and SID of one already in use, periodic advertising data being unauthenticated \u2014 can change the BASE at will; each new BASE is re-parsed.\n\nA crafted BASE therefore writes attacker-chosen bytes past the end of a fixed static object in .bss: up to roughly 236 bytes for an oversized metadata LTV, plus whole struct bt_bap_bass_subgroup records for each subgroup beyond CONFIG_BT_BAP_BASS_MAX_SUBGROUPS. This is memory corruption of adjacent Bluetooth-audio state reachable with no pairing, bonding or GATT connection, with a potential for remote code execution in the Bluetooth RX thread; in addition, the unvalidated metadata_len is forwarded to bt_bap_scan_delegator_mod_src(), which neither clamps it nor rejects it, leading to a further copy into the receive state and to out-of-bounds memory being disclosed in the BASS receive-state notification sent to a connected Broadcast Assistant.\n\nThe fix rejects a BASE carrying more subgroups than the receive state can hold (discarding the update entirely) and omits metadata that does not fit rather than copying it, and additionally honours the previously-ignored error return of the subgroup decode pass."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-120",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-787",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T07:16:38.508Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/5738f61f4128bb38508bab57342b1f7bf218d127"
},
{
"name": "GHSA-4qwc-2qfq-w2fj",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4qwc-2qfq-w2fj"
}
],
"title": "Out-of-bounds write in LE Audio Broadcast Sink when copying BASE subgroup metadata into the BASS receive state",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19570",
"datePublished": "2026-10-09T07:16:38.508Z",
"dateReserved": "2026-08-11T19:15:06.116Z",
"dateUpdated": "2026-10-09T17:58:32.024Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-15894 (GCVE-0-2026-15894)
Vulnerability from cvelistv5 – Published: 2026-10-07 08:55 – Updated: 2026-10-07 17:55
VLAI
EPSS
VEX
Title
Bluetooth Mesh solicitation PDU stack buffer overflow via oversized advertisement
Summary
The Bluetooth Mesh On-Demand Private Proxy solicitation handler in subsys/bluetooth/mesh/solicitation.c copies a received Solicitation PDU into a fixed 17-byte stack buffer without bounding the source length. In sol_pdu_decrypt(), out is allocated as NET_BUF_SIMPLE(17) and then filled with net_buf_simple_add_mem(out, in->data, in->len); net_buf_simple_add() guards its tailroom only with __ASSERT_NO_MSG, which is compiled out in production builds, so when in->len > 17 the underlying memcpy writes attacker-controlled bytes past the 17-byte stack buffer. The copy occurs before any decryption or authentication, so no key material is required to trigger it.
The oversized length arises because the mesh scan callback in subsys/bluetooth/mesh/adv.c calls net_buf_simple_restore() before dispatching to bt_mesh_sol_recv(), leaving buf->len covering the entire remaining advertising payload rather than just the Solicitation Service Data. After the parser locates the Service Data AD and consumes the Identification Type byte, the remaining buf->len is the 17-octet Network PDU plus any trailing advertising bytes, and prior to this fix there was no maximum-length check (only a minimum). An attacker can therefore append extra AD structures or padding after the Solicitation Service Data to make buf->len exceed 17.
bt_mesh_scan_cb() is registered directly as the BLE scan callback, so buf is raw, unauthenticated advertising data received over the air. Any device in radio range can send a non-connectable advertisement carrying a crafted mesh Proxy Solicitation to a node that has CONFIG_BT_MESH_OD_PRIV_PROXY_SRV enabled and is currently eligible to be solicited (GATT proxy disabled, On-Demand Private Proxy enabled), with no pairing, bonding, or provisioning. The result is an attacker-controlled stack overwrite — plausibly leading to remote code execution and at minimum a reliable remote denial of service. The fix trims buf->len to the spec-fixed 17 octets (dropping the PDU if fewer remain) before decryption.
Severity
8.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-07 17:54 UTC
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.4.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-15894",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-07T17:54:22.806164Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-07T17:55:22.647Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/mesh/adv.c",
"subsys/bluetooth/mesh/solicitation.c"
],
"programRoutines": [
{
"name": "bt_mesh_scan_cb"
},
{
"name": "bt_mesh_sol_recv"
},
{
"name": "sol_pdu_decrypt"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Bluetooth Mesh On-Demand Private Proxy solicitation handler in subsys/bluetooth/mesh/solicitation.c copies a received Solicitation PDU into a fixed 17-byte stack buffer without bounding the source length. In sol_pdu_decrypt(), out is allocated as NET_BUF_SIMPLE(17) and then filled with net_buf_simple_add_mem(out, in-\u003edata, in-\u003elen); net_buf_simple_add() guards its tailroom only with __ASSERT_NO_MSG, which is compiled out in production builds, so when in-\u003elen \u003e 17 the underlying memcpy writes attacker-controlled bytes past the 17-byte stack buffer. The copy occurs before any decryption or authentication, so no key material is required to trigger it.\n\nThe oversized length arises because the mesh scan callback in subsys/bluetooth/mesh/adv.c calls net_buf_simple_restore() before dispatching to bt_mesh_sol_recv(), leaving buf-\u003elen covering the entire remaining advertising payload rather than just the Solicitation Service Data. After the parser locates the Service Data AD and consumes the Identification Type byte, the remaining buf-\u003elen is the 17-octet Network PDU plus any trailing advertising bytes, and prior to this fix there was no maximum-length check (only a minimum). An attacker can therefore append extra AD structures or padding after the Solicitation Service Data to make buf-\u003elen exceed 17.\n\nbt_mesh_scan_cb() is registered directly as the BLE scan callback, so buf is raw, unauthenticated advertising data received over the air. Any device in radio range can send a non-connectable advertisement carrying a crafted mesh Proxy Solicitation to a node that has CONFIG_BT_MESH_OD_PRIV_PROXY_SRV enabled and is currently eligible to be solicited (GATT proxy disabled, On-Demand Private Proxy enabled), with no pairing, bonding, or provisioning. The result is an attacker-controlled stack overwrite \u2014 plausibly leading to remote code execution and at minimum a reliable remote denial of service. The fix trims buf-\u003elen to the spec-fixed 17 octets (dropping the PDU if fewer remain) before decryption."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-121",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-787",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-07T08:55:25.103Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/4416ad13677259d180f35ce44338578694e48184"
},
{
"name": "GHSA-x37p-38wq-cgwj",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-x37p-38wq-cgwj"
}
],
"title": "Bluetooth Mesh solicitation PDU stack buffer overflow via oversized advertisement",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-15894",
"datePublished": "2026-10-07T08:55:25.103Z",
"dateReserved": "2026-07-15T17:38:10.947Z",
"dateUpdated": "2026-10-07T17:55:22.647Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19186 (GCVE-0-2026-19186)
Vulnerability from cvelistv5 – Published: 2026-10-07 08:55 – Updated: 2026-10-15 22:10
VLAI
EPSS
VEX
Title
Integer underflow in IEEE 802.15.4 frame decryption leads to out-of-bounds read and write
Summary
ieee802154_decipher_data_frame() in subsys/net/l2/ieee802154/ieee802154_frame.c computed payload_len = net_pkt_get_len(pkt) - ll_hdr_len - authtag_len without first checking that the received frame is at least ll_hdr_len + authtag_len bytes long. All three variables are uint8_t, so a frame whose payload is shorter than the configured authentication tag makes the subtraction wrap around to a large value (up to 255).
The wrapped length is passed unchanged to ieee802154_decrypt_auth() and on to the CCM operation as cipher_pkt.in_len/out_buf_max, with apkt->tag pointing at frame + ll_hdr_len + payload_len. Because the receive buffer is allocated to the exact length of the frame received from the radio driver, the crypto layer then reads several hundred bytes past the end of the packet buffer and writes the same number of decrypted bytes back over it in place. The frame's authentication tag is only verified after this processing has taken place, so no key material, association or prior authentication is needed — a single crafted short frame from any device in radio range is sufficient. Frame validation in ieee802154_validate_frame() does not prevent it: a data frame is accepted with a one-byte payload.
The result is an out-of-bounds read and an out-of-bounds write of up to roughly 240 bytes into the adjacent network-buffer pool, corrupting other packets or allocator metadata and typically faulting the target. The out-of-bounds content is not attacker-chosen (it is ciphertext XOR keystream over out-of-bounds memory) and the frame is dropped when tag verification fails, so the primary impact is memory corruption and denial of service rather than information disclosure.
Exposure is limited to configurations that enable the experimental CONFIG_NET_L2_IEEE802154_SECURITY option, select a crypto device via CONFIG_NET_L2_IEEE802154_SECURITY_CRYPTO_DEV_NAME, and have established a security session with a level other than IEEE802154_SECURITY_LEVEL_NONE; with security disabled or at level NONE the tag length is zero and no underflow occurs. The fix rejects frames shorter than ll_hdr_len + authtag_len before the subtraction, and adds the matching guard on the transmit side in ieee802154_create_data_frame().
Severity
8.1 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-07 17:59 UTC
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.2.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19186",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-07T17:59:18.955003Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-07T18:01:37.189Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/net/l2/ieee802154/ieee802154_frame.c"
],
"programRoutines": [
{
"name": "ieee802154_decipher_data_frame"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.2.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "ieee802154_decipher_data_frame() in subsys/net/l2/ieee802154/ieee802154_frame.c computed payload_len = net_pkt_get_len(pkt) - ll_hdr_len - authtag_len without first checking that the received frame is at least ll_hdr_len + authtag_len bytes long. All three variables are uint8_t, so a frame whose payload is shorter than the configured authentication tag makes the subtraction wrap around to a large value (up to 255).\n\nThe wrapped length is passed unchanged to ieee802154_decrypt_auth() and on to the CCM operation as cipher_pkt.in_len/out_buf_max, with apkt-\u003etag pointing at frame + ll_hdr_len + payload_len. Because the receive buffer is allocated to the exact length of the frame received from the radio driver, the crypto layer then reads several hundred bytes past the end of the packet buffer and writes the same number of decrypted bytes back over it in place. The frame\u0027s authentication tag is only verified after this processing has taken place, so no key material, association or prior authentication is needed \u2014 a single crafted short frame from any device in radio range is sufficient. Frame validation in ieee802154_validate_frame() does not prevent it: a data frame is accepted with a one-byte payload.\n\nThe result is an out-of-bounds read and an out-of-bounds write of up to roughly 240 bytes into the adjacent network-buffer pool, corrupting other packets or allocator metadata and typically faulting the target. The out-of-bounds content is not attacker-chosen (it is ciphertext XOR keystream over out-of-bounds memory) and the frame is dropped when tag verification fails, so the primary impact is memory corruption and denial of service rather than information disclosure.\n\nExposure is limited to configurations that enable the experimental CONFIG_NET_L2_IEEE802154_SECURITY option, select a crypto device via CONFIG_NET_L2_IEEE802154_SECURITY_CRYPTO_DEV_NAME, and have established a security session with a level other than IEEE802154_SECURITY_LEVEL_NONE; with security disabled or at level NONE the tag length is zero and no underflow occurs. The fix rejects frames shorter than ll_hdr_len + authtag_len before the subtraction, and adds the matching guard on the transmit side in ieee802154_create_data_frame()."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.1,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-191",
"description": "integer-overflow",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-787",
"description": "integer-overflow",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T22:10:23.920Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/6d721de13a6026808f75578ecfee95a3592d5264"
},
{
"name": "GHSA-6x64-rwq6-j8x3",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6x64-rwq6-j8x3"
}
],
"title": "Integer underflow in IEEE 802.15.4 frame decryption leads to out-of-bounds read and write",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19186",
"datePublished": "2026-10-07T08:55:22.784Z",
"dateReserved": "2026-08-06T18:36:12.842Z",
"dateUpdated": "2026-10-15T22:10:23.920Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19185 (GCVE-0-2026-19185)
Vulnerability from cvelistv5 – Published: 2026-10-05 08:06 – Updated: 2026-10-05 14:06
VLAI
EPSS
VEX
Title
Unvalidated user-supplied buffer pointers in the I3C do_ccc system call handler allow kernel memory read/write from user mode
Summary
The system-call verifier for i3c_do_ccc() in drivers/i3c/i3c_handlers.c validated the outer struct i3c_ccc_payload, the broadcast ccc.data buffer and the targets.payloads[] array, but did not validate the per-target data buffers those array elements point at. Each struct i3c_ccc_target_payload carries its own data pointer and data_len, and neither was passed through K_SYSCALL_MEMORY() before the payload was handed to z_impl_i3c_do_ccc() and on to the controller driver. The verifier also operated on the caller's live structure rather than a snapshot, so validated fields could be changed by a second user thread between the check and the driver's use — unlike the sibling z_vrfy_i3c_transfer(), which has always copied its message array first.
The defect is only present in CONFIG_USERSPACE builds, where drivers/i3c/i3c_handlers.c is compiled. An unprivileged user-mode thread that has been granted access to the I3C controller device object — the ordinary way an application lets a user thread talk to I3C peripherals — can issue a direct CCC whose target payload data pointer names an arbitrary kernel address. Controller drivers dereference that pointer directly (for example drivers/i3c/i3c_mcux.c, drivers/i3c/i3c_cdns.c, drivers/i3c/i3c_stm32.c, drivers/i3c/i3c_npcx.c), using rnw to decide direction.
A read CCC therefore causes the kernel-mode driver to write bus-received bytes into an attacker-chosen kernel address for an attacker-chosen length, and a write CCC transmits kernel memory out onto the I3C bus. The result is an out-of-bounds kernel write plus a kernel memory disclosure, i.e. escalation from a user-mode thread to supervisor privilege, defeating the isolation CONFIG_USERSPACE is meant to provide.
The fix introduces copy_ccc_and_do(), which snapshots the payload, copies the target array into kernel memory with k_usermode_alloc_from_copy() (bounding num_targets to fewer than 32), validates each per-target buffer with K_SYSCALL_MEMORY() according to rnw, and copies the driver-written num_xfer and err fields back to the caller.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 14:06 UTC
CWE
- CWE-822 - memory-safety
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.2.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19185",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T14:06:01.294641Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T14:06:55.566Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/i3c/i3c_handlers.c"
],
"programRoutines": [
{
"name": "z_vrfy_i3c_do_ccc"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.2.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The system-call verifier for i3c_do_ccc() in drivers/i3c/i3c_handlers.c validated the outer struct i3c_ccc_payload, the broadcast ccc.data buffer and the targets.payloads[] array, but did not validate the per-target data buffers those array elements point at. Each struct i3c_ccc_target_payload carries its own data pointer and data_len, and neither was passed through K_SYSCALL_MEMORY() before the payload was handed to z_impl_i3c_do_ccc() and on to the controller driver. The verifier also operated on the caller\u0027s live structure rather than a snapshot, so validated fields could be changed by a second user thread between the check and the driver\u0027s use \u2014 unlike the sibling z_vrfy_i3c_transfer(), which has always copied its message array first.\n\nThe defect is only present in CONFIG_USERSPACE builds, where drivers/i3c/i3c_handlers.c is compiled. An unprivileged user-mode thread that has been granted access to the I3C controller device object \u2014 the ordinary way an application lets a user thread talk to I3C peripherals \u2014 can issue a direct CCC whose target payload data pointer names an arbitrary kernel address. Controller drivers dereference that pointer directly (for example drivers/i3c/i3c_mcux.c, drivers/i3c/i3c_cdns.c, drivers/i3c/i3c_stm32.c, drivers/i3c/i3c_npcx.c), using rnw to decide direction.\n\nA read CCC therefore causes the kernel-mode driver to write bus-received bytes into an attacker-chosen kernel address for an attacker-chosen length, and a write CCC transmits kernel memory out onto the I3C bus. The result is an out-of-bounds kernel write plus a kernel memory disclosure, i.e. escalation from a user-mode thread to supervisor privilege, defeating the isolation CONFIG_USERSPACE is meant to provide.\n\nThe fix introduces copy_ccc_and_do(), which snapshots the payload, copies the target array into kernel memory with k_usermode_alloc_from_copy() (bounding num_targets to fewer than 32), validates each per-target buffer with K_SYSCALL_MEMORY() according to rnw, and copies the driver-written num_xfer and err fields back to the caller."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-822",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T08:06:29.874Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/35562f22f40c6d2f31969a31f0a4902e5b067f27"
},
{
"name": "GHSA-pcrr-29j7-8w57",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-pcrr-29j7-8w57"
}
],
"title": "Unvalidated user-supplied buffer pointers in the I3C do_ccc system call handler allow kernel memory read/write from user mode",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19185",
"datePublished": "2026-10-05T08:06:29.874Z",
"dateReserved": "2026-08-06T18:36:11.738Z",
"dateUpdated": "2026-10-05T14:06:55.566Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-19184 (GCVE-0-2026-19184)
Vulnerability from cvelistv5 – Published: 2026-10-05 08:06 – Updated: 2026-10-05 13:23
VLAI
EPSS
VEX
Title
Out-of-bounds write in the NXP GAU ADC driver due to byte-versus-sample buffer size validation mismatch
Summary
The NXP GAU ADC driver (drivers/adc/adc_mcux_gau_adc.c) validated the caller-supplied sequence->buffer_size, which is expressed in bytes, against the number of active channels, which is a sample count. It then stored that byte count directly in data->results_length and used it in mcux_gau_adc_read_samples() as the number of uint16_t slots available. Because each conversion result occupies sizeof(uint16_t) bytes, a buffer that was accepted as "large enough" could be written with up to twice its size in bytes, so every sample past the buffer's midpoint was written out of bounds.
adc_read() and adc_read_async() are Zephyr system calls. The syscall verifier in drivers/adc/adc_handlers.c only confirms that the caller owns buffer_size writable bytes (K_SYSCALL_MEMORY_WRITE); deciding whether that size is sufficient for the requested channels and extra_samplings is delegated entirely to the driver. On a build with CONFIG_USERSPACE=y, a user-mode thread that has been granted the ADC device object could therefore submit a deliberately half-sized buffer and cause the driver's work-queue handler — which runs in supervisor mode, outside the caller's MPU restrictions — to write ADC conversion results past the end of that buffer, at an address and for a length of the caller's choosing.
The overrun is bounded by the requested sequence: with sequence->options->extra_samplings set, the sampling loop walks the buffer pointer forward across every sampling, so the total overrun can reach the full size of the supplied buffer (kilobytes for a large extra_samplings). The written words are 16-bit ADC conversion results, so the content is only partially attacker-influenced (via the selected analog input, gain and resolution), but the destination and length are fully controlled — sufficient for kernel memory corruption, a crash, or a userspace-to-kernel privilege escalation. Builds without CONFIG_USERSPACE, or on SoCs other than NXP RW61x with the GAU ADC node enabled, are not exposed to the privilege boundary; there the same defect only causes a silent overflow when the application itself passes an undersized buffer.
The fix replaces the ad-hoc check with the shared adc_sequence_validate_buffer() helper (validating against num_channels * sizeof(uint16_t)), stores buffer_size / sizeof(uint16_t) in results_length, and corrects the loop bound to a post-decrement so exactly the available number of slots may be written.
Severity
8.4 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 13:23 UTC
CWE
- CWE-787 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.7.0 , < 4.5.0
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-19184",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T13:23:22.615234Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T13:23:31.086Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/adc/adc_mcux_gau_adc.c"
],
"programRoutines": [
{
"name": "mcux_gau_adc_do_read"
},
{
"name": "mcux_gau_adc_read_samples"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.7.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The NXP GAU ADC driver (drivers/adc/adc_mcux_gau_adc.c) validated the caller-supplied sequence-\u003ebuffer_size, which is expressed in bytes, against the number of active channels, which is a sample count. It then stored that byte count directly in data-\u003eresults_length and used it in mcux_gau_adc_read_samples() as the number of uint16_t slots available. Because each conversion result occupies sizeof(uint16_t) bytes, a buffer that was accepted as \"large enough\" could be written with up to twice its size in bytes, so every sample past the buffer\u0027s midpoint was written out of bounds.\n\nadc_read() and adc_read_async() are Zephyr system calls. The syscall verifier in drivers/adc/adc_handlers.c only confirms that the caller owns buffer_size writable bytes (K_SYSCALL_MEMORY_WRITE); deciding whether that size is sufficient for the requested channels and extra_samplings is delegated entirely to the driver. On a build with CONFIG_USERSPACE=y, a user-mode thread that has been granted the ADC device object could therefore submit a deliberately half-sized buffer and cause the driver\u0027s work-queue handler \u2014 which runs in supervisor mode, outside the caller\u0027s MPU restrictions \u2014 to write ADC conversion results past the end of that buffer, at an address and for a length of the caller\u0027s choosing.\n\nThe overrun is bounded by the requested sequence: with sequence-\u003eoptions-\u003eextra_samplings set, the sampling loop walks the buffer pointer forward across every sampling, so the total overrun can reach the full size of the supplied buffer (kilobytes for a large extra_samplings). The written words are 16-bit ADC conversion results, so the content is only partially attacker-influenced (via the selected analog input, gain and resolution), but the destination and length are fully controlled \u2014 sufficient for kernel memory corruption, a crash, or a userspace-to-kernel privilege escalation. Builds without CONFIG_USERSPACE, or on SoCs other than NXP RW61x with the GAU ADC node enabled, are not exposed to the privilege boundary; there the same defect only causes a silent overflow when the application itself passes an undersized buffer.\n\nThe fix replaces the ad-hoc check with the shared adc_sequence_validate_buffer() helper (validating against num_channels * sizeof(uint16_t)), stores buffer_size / sizeof(uint16_t) in results_length, and corrects the loop bound to a post-decrement so exactly the available number of slots may be written."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.4,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T08:06:22.681Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/82b11958065aa85f8644ddc318ff4a328d1443c8"
},
{
"name": "GHSA-j86w-mfgw-fxj9",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j86w-mfgw-fxj9"
}
],
"title": "Out-of-bounds write in the NXP GAU ADC driver due to byte-versus-sample buffer size validation mismatch",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-19184",
"datePublished": "2026-10-05T08:06:22.681Z",
"dateReserved": "2026-08-06T18:36:10.589Z",
"dateUpdated": "2026-10-05T13:23:31.086Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17053 (GCVE-0-2026-17053)
Vulnerability from cvelistv5 – Published: 2026-10-01 15:08 – Updated: 2026-10-01 16:03
VLAI
EPSS
VEX
Title
SMBus callback-removal syscalls accept an unvalidated user pointer, letting user threads manipulate kernel callback state
Summary
The SMBus driver API exposed smbus_smbalert_remove_cb() and smbus_host_notify_remove_cb() as Zephyr syscalls. Their verifiers in drivers/smbus/smbus_handlers.c validated only the dev argument with K_SYSCALL_OBJ(dev, K_OBJ_DRIVER_SMBUS) and forwarded the caller-supplied struct smbus_callback *cb pointer into kernel-mode driver code without any K_SYSCALL_MEMORY_READ/K_SYSCALL_MEMORY_WRITE validation. A companion change in 2023 had already removed the matching smbus_smbalert_set_cb() / smbus_host_notify_set_cb() syscalls for this reason, but the two removal syscalls were left exposed.
On a build with CONFIG_USERSPACE=y, CONFIG_SMBUS=y and a driver implementing the callback operations (drivers/smbus/intel_pch_smbus.c with CONFIG_SMBUS_INTEL_PCH_SMBALERT/CONFIG_SMBUS_INTEL_PCH_HOST_NOTIFY, or drivers/smbus/smbus_stm32.c with CONFIG_SMBUS_STM32_SMBALERT), any user-mode thread that has been granted the SMBus device object can invoke these syscalls with an arbitrary pointer. The value reaches smbus_callback_remove() in drivers/smbus/smbus_utils.h, which uses it as a node identity against the kernel's sys_slist_t of registered callbacks.
The consequence is that an unprivileged thread can unregister an SMBALERT or Host Notify callback that a supervisor-mode component registered, silently disabling alert handling for the rest of the system; because Zephyr images have fixed symbol addresses and the syscall returns 0 on a hit versus -ENOENT on a miss, the target address is both derivable and searchable. In builds with CONFIG_ASSERT=y the __ASSERT(callback->handler, ...) check additionally dereferences the caller-supplied address in supervisor mode, so a bogus pointer raises a kernel-mode fault and a fatal system error, and the fault/no-fault outcome discloses which addresses are mapped.
The fix removes both syscall entry points, demoting the two functions to ordinary static inline calls so that callback list manipulation is available only to supervisor-mode code. There is no impact on builds without CONFIG_USERSPACE, and no impact on configurations that do not enable an SMBus driver with SMBALERT or Host Notify support.
Severity
4.4 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-01 16:03 UTC
CWE
- CWE-862 - auth
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.4.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-17053",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-01T16:03:23.442120Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-01T16:03:31.409Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"drivers/smbus/smbus_handlers.c",
"include/zephyr/drivers/smbus.h"
],
"programRoutines": [
{
"name": "smbus_callback_remove"
},
{
"name": "z_impl_smbus_host_notify_remove_cb"
},
{
"name": "z_impl_smbus_smbalert_remove_cb"
},
{
"name": "z_vrfy_smbus_host_notify_remove_cb"
},
{
"name": "z_vrfy_smbus_smbalert_remove_cb"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The SMBus driver API exposed smbus_smbalert_remove_cb() and smbus_host_notify_remove_cb() as Zephyr syscalls. Their verifiers in drivers/smbus/smbus_handlers.c validated only the dev argument with K_SYSCALL_OBJ(dev, K_OBJ_DRIVER_SMBUS) and forwarded the caller-supplied struct smbus_callback *cb pointer into kernel-mode driver code without any K_SYSCALL_MEMORY_READ/K_SYSCALL_MEMORY_WRITE validation. A companion change in 2023 had already removed the matching smbus_smbalert_set_cb() / smbus_host_notify_set_cb() syscalls for this reason, but the two removal syscalls were left exposed.\n\nOn a build with CONFIG_USERSPACE=y, CONFIG_SMBUS=y and a driver implementing the callback operations (drivers/smbus/intel_pch_smbus.c with CONFIG_SMBUS_INTEL_PCH_SMBALERT/CONFIG_SMBUS_INTEL_PCH_HOST_NOTIFY, or drivers/smbus/smbus_stm32.c with CONFIG_SMBUS_STM32_SMBALERT), any user-mode thread that has been granted the SMBus device object can invoke these syscalls with an arbitrary pointer. The value reaches smbus_callback_remove() in drivers/smbus/smbus_utils.h, which uses it as a node identity against the kernel\u0027s sys_slist_t of registered callbacks.\n\nThe consequence is that an unprivileged thread can unregister an SMBALERT or Host Notify callback that a supervisor-mode component registered, silently disabling alert handling for the rest of the system; because Zephyr images have fixed symbol addresses and the syscall returns 0 on a hit versus -ENOENT on a miss, the target address is both derivable and searchable. In builds with CONFIG_ASSERT=y the __ASSERT(callback-\u003ehandler, ...) check additionally dereferences the caller-supplied address in supervisor mode, so a bogus pointer raises a kernel-mode fault and a fatal system error, and the fault/no-fault outcome discloses which addresses are mapped.\n\nThe fix removes both syscall entry points, demoting the two functions to ordinary static inline calls so that callback list manipulation is available only to supervisor-mode code. There is no impact on builds without CONFIG_USERSPACE, and no impact on configurations that do not enable an SMBus driver with SMBALERT or Host Notify support."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 4.4,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "auth",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-01T15:08:52.721Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/331df881a8b8cb4296699a8251c9fd74a4308f3d"
},
{
"name": "GHSA-hqh5-956f-5x2r",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-hqh5-956f-5x2r"
}
],
"title": "SMBus callback-removal syscalls accept an unvalidated user pointer, letting user threads manipulate kernel callback state",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17053",
"datePublished": "2026-10-01T15:08:52.721Z",
"dateReserved": "2026-07-24T13:31:06.974Z",
"dateUpdated": "2026-10-01T16:03:31.409Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}