Search
Find a vulnerability
Search criteria
532 vulnerabilities found for zephyr by zephyrproject
CVE-2026-17053 (GCVE-0-2026-17053)
Vulnerability from nvd – 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"
}
CVE-2026-18747 (GCVE-0-2026-18747)
Vulnerability from nvd – Published: 2026-09-28 23:25 – Updated: 2026-09-30 13:44
VLAI
EPSS
VEX
Title
Integer underflow of net_buf length in the MCUmgr serial (SMP over console) transport leads to out-of-bounds read
Summary
The MCUmgr SMP-over-console transport decodes a base64 frame, reads a 16-bit packet length from it, verifies a CRC and then unconditionally strips the trailing CRC with rx_ctxt->nb->len -= 2U; in mcumgr_serial_process_frag() (subsys/mgmt/mcumgr/transport/src/serial_util.c). mcumgr_serial_extract_len() accepted any declared length, including 0 and 1, and a packet declaring length 0 passes the checksum test for free because crc16_itu_t() over zero bytes returns the zero seed. Since net_buf::len is a uint16_t, the subtraction underflows and the buffer is handed to SMP claiming roughly 65 KB of payload while its data area is only CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE bytes (default 384).
The trigger is a single unauthenticated 7-byte line on the management console — the 0x06 0x09 packet marker followed by the base64 group AAA= and a newline — delivered to any transport built on this helper: CONFIG_MCUMGR_TRANSPORT_UART (smp_uart.c) or CONFIG_MCUMGR_TRANSPORT_SHELL (smp_shell.c), both of which select MCUMGR_TRANSPORT_SERIAL_HAS_SMP_OVER_CONSOLE. No prior session state, fragmentation or credentials are required to trigger the underflow, and the malformed frame is mishandled before any command handler or command-level access control runs. The attacker only needs write access to that console, which on many boards is a USB CDC-ACM port rather than a bare UART header.
With the inflated length, smp_process_request_packet() in subsys/mgmt/mcumgr/smp/src/smp.c loses its bound: cbor_nb_reader_init() gives the CBOR decoder a ~65 KB window into a 384-byte buffer, and each request header's nh_len is checked only against the inflated length. On its own the 7-byte frame re-parses whatever stale bytes the reused pool buffer still holds, typically a replay of the previously received request followed by a parse error, without leaving the buffer. Because the transport is unauthenticated, though, the attacker also controls the frames sent before the trigger, and can stage buffer contents so that a request succeeds with an nh_len larger than the buffer; net_buf_pull(), guarded only by __ASSERT_NO_MSG, then moves the parse cursor out of bounds and the loop reads further headers and CBOR from adjacent memory. The consequence is an out-of-bounds read that can fault the MCUmgr thread (denial of service); memory disclosure is also possible, since the default-enabled os echo handler (CONFIG_MCUMGR_GRP_OS_ECHO) decodes its string inside that window and copies it into its response. There is no integrity gain beyond what the unauthenticated transport already permits.
The fix rejects any declared packet length of two bytes or fewer in mcumgr_serial_extract_len(), so the CRC-strip subtraction can no longer underflow. The identical pattern remains in the test-only loopback transport subsys/mgmt/mcumgr/transport/src/smp_dummy.c (CONFIG_MCUMGR_TRANSPORT_DUMMY), which has no external input path and therefore carries no practical exposure.
Severity
6.8 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 13:44 UTC
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-18747",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T13:44:27.727115Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T13:44:37.055Z",
"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/mcumgr/transport/src/serial_util.c"
],
"programRoutines": [
{
"name": "mcumgr_serial_extract_len"
},
{
"name": "mcumgr_serial_process_frag"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "1.11.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The MCUmgr SMP-over-console transport decodes a base64 frame, reads a 16-bit packet length from it, verifies a CRC and then unconditionally strips the trailing CRC with rx_ctxt-\u003enb-\u003elen -= 2U; in mcumgr_serial_process_frag() (subsys/mgmt/mcumgr/transport/src/serial_util.c). mcumgr_serial_extract_len() accepted any declared length, including 0 and 1, and a packet declaring length 0 passes the checksum test for free because crc16_itu_t() over zero bytes returns the zero seed. Since net_buf::len is a uint16_t, the subtraction underflows and the buffer is handed to SMP claiming roughly 65 KB of payload while its data area is only CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE bytes (default 384).\n\nThe trigger is a single unauthenticated 7-byte line on the management console \u2014 the 0x06 0x09 packet marker followed by the base64 group AAA= and a newline \u2014 delivered to any transport built on this helper: CONFIG_MCUMGR_TRANSPORT_UART (smp_uart.c) or CONFIG_MCUMGR_TRANSPORT_SHELL (smp_shell.c), both of which select MCUMGR_TRANSPORT_SERIAL_HAS_SMP_OVER_CONSOLE. No prior session state, fragmentation or credentials are required to trigger the underflow, and the malformed frame is mishandled before any command handler or command-level access control runs. The attacker only needs write access to that console, which on many boards is a USB CDC-ACM port rather than a bare UART header.\n\nWith the inflated length, smp_process_request_packet() in subsys/mgmt/mcumgr/smp/src/smp.c loses its bound: cbor_nb_reader_init() gives the CBOR decoder a ~65 KB window into a 384-byte buffer, and each request header\u0027s nh_len is checked only against the inflated length. On its own the 7-byte frame re-parses whatever stale bytes the reused pool buffer still holds, typically a replay of the previously received request followed by a parse error, without leaving the buffer. Because the transport is unauthenticated, though, the attacker also controls the frames sent before the trigger, and can stage buffer contents so that a request succeeds with an nh_len larger than the buffer; net_buf_pull(), guarded only by __ASSERT_NO_MSG, then moves the parse cursor out of bounds and the loop reads further headers and CBOR from adjacent memory. The consequence is an out-of-bounds read that can fault the MCUmgr thread (denial of service); memory disclosure is also possible, since the default-enabled os echo handler (CONFIG_MCUMGR_GRP_OS_ECHO) decodes its string inside that window and copies it into its response. There is no integrity gain beyond what the unauthenticated transport already permits.\n\nThe fix rejects any declared packet length of two bytes or fewer in mcumgr_serial_extract_len(), so the CRC-strip subtraction can no longer underflow. The identical pattern remains in the test-only loopback transport subsys/mgmt/mcumgr/transport/src/smp_dummy.c (CONFIG_MCUMGR_TRANSPORT_DUMMY), which has no external input path and therefore carries no practical exposure."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.8,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/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": "integer-overflow",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-191",
"description": "integer-overflow",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-28T23:25:26.081Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/f7fc3e779a59c68c96eaf63a6b03ac7489f5e4a5"
},
{
"name": "GHSA-g6cx-xj75-hvfw",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-g6cx-xj75-hvfw"
}
],
"title": "Integer underflow of net_buf length in the MCUmgr serial (SMP over console) transport leads to out-of-bounds read",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18747",
"datePublished": "2026-09-28T23:25:26.081Z",
"dateReserved": "2026-08-03T21:22:12.879Z",
"dateUpdated": "2026-09-30T13:44:37.055Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18746 (GCVE-0-2026-18746)
Vulnerability from nvd – Published: 2026-09-28 23:25 – Updated: 2026-09-30 13:44
VLAI
EPSS
VEX
Title
NULL pointer dereference in Zephyr LwM2M client when the CoAP Block1 context pool is exhausted
Summary
parse_write_op() in subsys/net/lib/lwm2m/lwm2m_message_handling.c handles inbound CoAP WRITE/CREATE requests that carry a Block1 option. For the first block of a transfer it called init_block_ctx() and then immediately stored the peer-selected block size with block_ctx->ctx.block_size = block_size before inspecting the return code. init_block_ctx() sets the caller's pointer to NULL and returns -ENOMEM when no entry of the static block1_contexts[] pool is free or timed out, so that store dereferences a NULL pointer.
The pool holds CONFIG_LWM2M_NUM_BLOCK1_CONTEXT entries (default 3) and an entry is only reclaimed once its transfer completes, fails, or ages past 30 seconds. A peer that reaches the client's LwM2M socket can therefore start three block-wise writes on three distinct object paths with the CoAP More bit set and leave them incomplete, then send the first block of a fourth write on a new path to reach the unguarded dereference. Reachability is gated only by the connected UDP socket's source-address filter unless CONFIG_LWM2M_DTLS_SUPPORT is enabled — which has no default — so in a NoSec deployment an on-path or address-spoofing attacker needs no credentials; the same sequence is also reachable from a bootstrap or lower-trust server, and can be hit accidentally by a legitimate server running four concurrent block transfers.
The write targets a fixed low address with a value between 0 and 7, so the consequence is a fatal memory fault (BusFault or corrupted low memory leading to a fault) rather than a usable memory-corruption primitive: the device crashes or resets. Confidentiality and integrity are not affected. The fix moves the store below the guard and validates the context pointer itself instead of the return code, so the context is only touched once it is known to be valid.
Severity
5.9 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 13:44 UTC
CWE
- CWE-476 - memory-safety
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-18746",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T13:44:03.814947Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T13:44:12.453Z",
"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/lib/lwm2m/lwm2m_message_handling.c"
],
"programRoutines": [
{
"name": "parse_write_op"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.7.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "parse_write_op() in subsys/net/lib/lwm2m/lwm2m_message_handling.c handles inbound CoAP WRITE/CREATE requests that carry a Block1 option. For the first block of a transfer it called init_block_ctx() and then immediately stored the peer-selected block size with block_ctx-\u003ectx.block_size = block_size before inspecting the return code. init_block_ctx() sets the caller\u0027s pointer to NULL and returns -ENOMEM when no entry of the static block1_contexts[] pool is free or timed out, so that store dereferences a NULL pointer.\n\nThe pool holds CONFIG_LWM2M_NUM_BLOCK1_CONTEXT entries (default 3) and an entry is only reclaimed once its transfer completes, fails, or ages past 30 seconds. A peer that reaches the client\u0027s LwM2M socket can therefore start three block-wise writes on three distinct object paths with the CoAP More bit set and leave them incomplete, then send the first block of a fourth write on a new path to reach the unguarded dereference. Reachability is gated only by the connected UDP socket\u0027s source-address filter unless CONFIG_LWM2M_DTLS_SUPPORT is enabled \u2014 which has no default \u2014 so in a NoSec deployment an on-path or address-spoofing attacker needs no credentials; the same sequence is also reachable from a bootstrap or lower-trust server, and can be hit accidentally by a legitimate server running four concurrent block transfers.\n\nThe write targets a fixed low address with a value between 0 and 7, so the consequence is a fatal memory fault (BusFault or corrupted low memory leading to a fault) rather than a usable memory-corruption primitive: the device crashes or resets. Confidentiality and integrity are not affected. The fix moves the store below the guard and validates the context pointer itself instead of the return code, so the context is only touched once it is known to be valid."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/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-09-28T23:25:24.971Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/e61790f776863032925e96819f84cafc9a958b8a"
},
{
"name": "GHSA-4q9g-2mhh-m7w7",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4q9g-2mhh-m7w7"
}
],
"title": "NULL pointer dereference in Zephyr LwM2M client when the CoAP Block1 context pool is exhausted",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18746",
"datePublished": "2026-09-28T23:25:24.971Z",
"dateReserved": "2026-08-03T21:22:11.665Z",
"dateUpdated": "2026-09-30T13:44:12.453Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18417 (GCVE-0-2026-18417)
Vulnerability from nvd – Published: 2026-09-28 23:25 – Updated: 2026-09-30 13:43
VLAI
EPSS
VEX
Title
Wild pointer dereference in Zephyr BSD sockets when a TCP listening socket reports an asynchronous error
Summary
The native BSD-socket layer recorded a pending asynchronous socket error by type-punning it into struct net_context's void user_data field (ctx->user_data = INT_TO_POINTER(-status) in zsock_accepted_cb(), zsock_received_cb(), zsock_connected_cb() and zsock_close_ctx() in subsys/net/lib/sockets/sockets_inet.c), reading it back with POINTER_TO_INT(). That same field is owned by the network stack for listening TCP contexts: net_tcp_accept() stores the parent context pointer there and the TCP core passes it back to the registered accept callback. A failed accept therefore left a small integer (an errno value) where the stack expected a struct net_context .
When the network interface carrying a listening TCP socket goes down, close_tcp_conn() in subsys/net/ip/tcp.c invokes the accept callback with -ENETDOWN and the context's user_data. In v4.3.0 the callback was not disarmed afterwards, so a second interface-down event forwarded the previously stored errno to zsock_accepted_cb(), which dereferenced it as the parent context and performed several stores through it (sock_set_error()'s read-modify-write of socket_data, k_fifo_cancel_wait(&parent->recv_q)) — the crash described in the fix's commit message. v4.3.1 and v4.4.x carry a later change clearing conn->accept_cb after the error callback (269cb8823d3 on the v4.3 branch, 913fae5169425550f2364655298fceb79b320066 on main), which closes that repeat path; on those releases the poisoned cookie remains reachable only by a narrower race, a handshake completing alongside the interface-down still passing the stale cookie to k_fifo_put(&parent->accept_q, ...), and by getsockopt(SO_ERROR), which reads the field back unconditionally.
On v4.3.0 an application that keeps a listening TCP socket open across repeated link-down events is sufficient to reach the defect; the triggering condition is a network-interface state change, not attacker-supplied packet data, so the practical attacker is one able to force the link down repeatedly (for example an adjacent attacker disrupting a wireless link) or one with local/physical access. Because both the faulting address and the stored data are fixed small constants derived from the errno value, the outcome is a wild-pointer access leading to a kernel fatal error — a denial of service (device crash or reset) rather than an attacker-directed memory corruption.
The fix stores the pending error in a dedicated net_context.sock_error field and converts every producer and consumer to sock_set_error()/sock_get_error(), leaving user_data untouched. As a side effect it also stops getsockopt(SO_ERROR) — which is evaluated unconditionally — from returning the kernel address held in user_data to a userspace application.
Severity
6.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 13:43 UTC
CWE
- CWE-843 - memory-safety
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-18417",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T13:43:32.816350Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T13:43:48.703Z",
"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": [
"include/zephyr/net/net_context.h",
"subsys/net/lib/sockets/sockets_inet.c",
"subsys/net/lib/sockets/sockets_internal.h"
],
"programRoutines": [
{
"name": "close_tcp_conn"
},
{
"name": "zsock_accepted_cb"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The native BSD-socket layer recorded a pending asynchronous socket error by type-punning it into struct net_context\u0027s void user_data field (ctx-\u003euser_data = INT_TO_POINTER(-status) in zsock_accepted_cb(), zsock_received_cb(), zsock_connected_cb() and zsock_close_ctx() in subsys/net/lib/sockets/sockets_inet.c), reading it back with POINTER_TO_INT(). That same field is owned by the network stack for listening TCP contexts: net_tcp_accept() stores the parent context pointer there and the TCP core passes it back to the registered accept callback. A failed accept therefore left a small integer (an errno value) where the stack expected a struct net_context .\n\nWhen the network interface carrying a listening TCP socket goes down, close_tcp_conn() in subsys/net/ip/tcp.c invokes the accept callback with -ENETDOWN and the context\u0027s user_data. In v4.3.0 the callback was not disarmed afterwards, so a second interface-down event forwarded the previously stored errno to zsock_accepted_cb(), which dereferenced it as the parent context and performed several stores through it (sock_set_error()\u0027s read-modify-write of socket_data, k_fifo_cancel_wait(\u0026parent-\u003erecv_q)) \u2014 the crash described in the fix\u0027s commit message. v4.3.1 and v4.4.x carry a later change clearing conn-\u003eaccept_cb after the error callback (269cb8823d3 on the v4.3 branch, 913fae5169425550f2364655298fceb79b320066 on main), which closes that repeat path; on those releases the poisoned cookie remains reachable only by a narrower race, a handshake completing alongside the interface-down still passing the stale cookie to k_fifo_put(\u0026parent-\u003eaccept_q, ...), and by getsockopt(SO_ERROR), which reads the field back unconditionally.\n\nOn v4.3.0 an application that keeps a listening TCP socket open across repeated link-down events is sufficient to reach the defect; the triggering condition is a network-interface state change, not attacker-supplied packet data, so the practical attacker is one able to force the link down repeatedly (for example an adjacent attacker disrupting a wireless link) or one with local/physical access. Because both the faulting address and the stored data are fixed small constants derived from the errno value, the outcome is a wild-pointer access leading to a kernel fatal error \u2014 a denial of service (device crash or reset) rather than an attacker-directed memory corruption.\n\nThe fix stores the pending error in a dedicated net_context.sock_error field and converts every producer and consumer to sock_set_error()/sock_get_error(), leaving user_data untouched. As a side effect it also stops getsockopt(SO_ERROR) \u2014 which is evaluated unconditionally \u2014 from returning the kernel address held in user_data to a userspace application."
}
],
"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-843",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-28T23:25:23.903Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/ef370a57d07637aaee8cec7b0bcebf4002ac8f54"
},
{
"name": "GHSA-p8r8-8mw8-3wf9",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-p8r8-8mw8-3wf9"
}
],
"title": "Wild pointer dereference in Zephyr BSD sockets when a TCP listening socket reports an asynchronous error",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18417",
"datePublished": "2026-09-28T23:25:23.903Z",
"dateReserved": "2026-07-30T17:54:13.939Z",
"dateUpdated": "2026-09-30T13:43:48.703Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18416 (GCVE-0-2026-18416)
Vulnerability from nvd – Published: 2026-09-28 20:00 – Updated: 2026-09-30 15:28
VLAI
EPSS
VEX
Title
Out-of-bounds read in CoAP well-known-core Uri-Query href matching (match_path_uri)
Summary
The CoAP link-format helper match_path_uri() in subsys/net/lib/coap/coap_link_format.c compares a registered resource path against the URI carried in a Uri-Query href= option. That URI is not NUL terminated, but the inner character loop advanced its index k once per path character without ever testing it against the option length len. When a registered path segment is longer than the supplied URI and the URI is a prefix of it, the loop reads uri[len] and beyond, past the end of the option value.
The path is reached from coap_well_known_core_get_len() and coap_well_known_core_get() via match_queries_resource(), i.e. by any unauthenticated GET /.well-known/core?href=/<prefix> request to a device that serves /.well-known/core (for the CoAP server subsystem, CONFIG_COAP_SERVER_WELL_KNOWN_CORE, default y) and has at least one resource that declares struct coap_core_metadata attributes.
The over-read does not reach the receive buffer. The well-known-core builders parse the query into a stack-local struct coap_option, whose value is a fixed array (value[12], or CONFIG_COAP_EXTENDED_OPTIONS_LEN_VALUE bytes) that the option bytes are copied into, so uri points into that copy. Reading past len therefore reads the unused, uninitialized tail of the array and, when the option fills it, the bytes just past it in the same stack frame. (In the ZoAP library of v1.8.0 to v1.9.x the option value was instead a pointer into the received packet, and the over-read ran past the option inside the packet buffer.)
The impact is bounded. The number of bytes read past the end is limited by the length of the resource path segment, and each additional byte is only read if it happens to equal the next path character, so in practice the over-read is one byte. It also cannot influence the response: returning a match requires the final compared index to be len - 1 or len, both in bounds, so out-of-bounds bytes only ever steer the loop to the next candidate resource. The consequence is undefined behaviour, not information disclosure and not a matching error.
The fix adds a k >= len guard at the top of the inner loop, so every uri[k] dereference is within the option value while still allowing a trailing * wildcard to match a longer path.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 15:18 UTC
CWE
- CWE-125 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
1.8.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18416",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T15:18:49.506461Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T15:28:20.615Z",
"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/lib/coap/coap_link_format.c"
],
"programRoutines": [
{
"name": "coap_well_known_core_get"
},
{
"name": "coap_well_known_core_get_len"
},
{
"name": "match_path_uri"
},
{
"name": "match_queries_resource"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "1.8.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The CoAP link-format helper match_path_uri() in subsys/net/lib/coap/coap_link_format.c compares a registered resource path against the URI carried in a Uri-Query href= option. That URI is not NUL terminated, but the inner character loop advanced its index k once per path character without ever testing it against the option length len. When a registered path segment is longer than the supplied URI and the URI is a prefix of it, the loop reads uri[len] and beyond, past the end of the option value.\n\nThe path is reached from coap_well_known_core_get_len() and coap_well_known_core_get() via match_queries_resource(), i.e. by any unauthenticated GET /.well-known/core?href=/\u003cprefix\u003e request to a device that serves /.well-known/core (for the CoAP server subsystem, CONFIG_COAP_SERVER_WELL_KNOWN_CORE, default y) and has at least one resource that declares struct coap_core_metadata attributes.\n\nThe over-read does not reach the receive buffer. The well-known-core builders parse the query into a stack-local struct coap_option, whose value is a fixed array (value[12], or CONFIG_COAP_EXTENDED_OPTIONS_LEN_VALUE bytes) that the option bytes are copied into, so uri points into that copy. Reading past len therefore reads the unused, uninitialized tail of the array and, when the option fills it, the bytes just past it in the same stack frame. (In the ZoAP library of v1.8.0 to v1.9.x the option value was instead a pointer into the received packet, and the over-read ran past the option inside the packet buffer.)\n\nThe impact is bounded. The number of bytes read past the end is limited by the length of the resource path segment, and each additional byte is only read if it happens to equal the next path character, so in practice the over-read is one byte. It also cannot influence the response: returning a match requires the final compared index to be len - 1 or len, both in bounds, so out-of-bounds bytes only ever steer the loop to the next candidate resource. The consequence is undefined behaviour, not information disclosure and not a matching error.\n\nThe fix adds a k \u003e= len guard at the top of the inner loop, so every uri[k] dereference is within the option value while still allowing a trailing * wildcard to match a longer path."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 3.7,
"baseSeverity": "LOW",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-28T20:00:02.425Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/ef5b303dc88fb5159850623a2b51b590c36fa5bc"
},
{
"name": "GHSA-m3mv-vvm4-h58g",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-m3mv-vvm4-h58g"
}
],
"title": "Out-of-bounds read in CoAP well-known-core Uri-Query href matching (match_path_uri)",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18416",
"datePublished": "2026-09-28T20:00:02.425Z",
"dateReserved": "2026-07-30T17:54:12.762Z",
"dateUpdated": "2026-09-30T15:28:20.615Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18415 (GCVE-0-2026-18415)
Vulnerability from nvd – Published: 2026-09-28 20:00 – Updated: 2026-09-30 15:28
VLAI
EPSS
VEX
Title
Out-of-bounds write in the IEEE 802.15.4 L2 transmit path for oversized non-6LoWPAN frames
Summary
ieee802154_send() in subsys/net/l2/ieee802154/ieee802154.c copies the outgoing packet into a single fixed 125-byte transmit buffer (tx_frame_buf_pool, sized IEEE802154_MTU). In builds with CONFIG_NET_L2_IEEE802154_FRAGMENT enabled (the default whenever CONFIG_NET_6LO is set), the branch taken when 6LoWPAN fragmentation is not required performed an unchecked net_buf_add_mem(frame_buf, pkt_buf->data, pkt_buf->len). The only guard was __ASSERT_NO_MSG() inside net_buf_simple_add(), which is compiled out without CONFIG_ASSERT, so an oversized packet silently overran the frame buffer.
The defect is not reachable from the radio: for NET_AF_INET6 packets ieee802154_6lo_encode_pkt() compares the whole packet length against IEEE802154_MTU and takes the fragmentation path when it does not fit, so every buffer copied on the unfragmented branch is within bounds. It is reachable through NET_AF_PACKET sockets bound to an 802.15.4 interface: for NET_SOCK_RAW the 6LoWPAN block is skipped entirely and for NET_SOCK_DGRAM it returns early on the address-family test, leaving no length validation anywhere on the transmit path (net_context_sendto() and net_if_tx() apply none, and pkt_buffer_length() does not clamp the allocation for this L2).
An application — or, in a CONFIG_USERSPACE build, an unprivileged application thread using the zsock_socket()/zsock_sendto() syscalls — can therefore drive a supervisor-mode out-of-bounds write of chosen bytes past the 125-byte pool buffer. With the default CONFIG_NET_BUF_FIXED_DATA_SIZE of 128 bytes the overrun is bounded to roughly ll_hdr_len + 3 bytes; with CONFIG_NET_BUF_VARIABLE_DATA_SIZE a single storage buffer can be as large as CONFIG_NET_PKT_BUF_TX_DATA_POOL_SIZE, making the overrun far larger. The consequence is corruption of memory adjacent to the pool, with a crash or further compromise of kernel state as the practical impact.
The fix validates ll_hdr_len + net_pkt_get_len(pkt) + authtag_len against IEEE802154_MTU before any copy and adds a tailroom-checking copy_pkt_to_frame() helper that returns -EMSGSIZE instead of overrunning the buffer. The same change also linearizes the whole net_buf chain into one MAC frame, so packet storage boundaries no longer become frame boundaries on the wire.
Severity
6.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 15:18 UTC
CWE
- CWE-787 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.2.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18415",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T15:18:58.650860Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T15:28:20.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": [
"subsys/net/l2/ieee802154/ieee802154.c"
],
"programRoutines": [
{
"name": "ieee802154_send"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.2.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "ieee802154_send() in subsys/net/l2/ieee802154/ieee802154.c copies the outgoing packet into a single fixed 125-byte transmit buffer (tx_frame_buf_pool, sized IEEE802154_MTU). In builds with CONFIG_NET_L2_IEEE802154_FRAGMENT enabled (the default whenever CONFIG_NET_6LO is set), the branch taken when 6LoWPAN fragmentation is not required performed an unchecked net_buf_add_mem(frame_buf, pkt_buf-\u003edata, pkt_buf-\u003elen). The only guard was __ASSERT_NO_MSG() inside net_buf_simple_add(), which is compiled out without CONFIG_ASSERT, so an oversized packet silently overran the frame buffer.\n\nThe defect is not reachable from the radio: for NET_AF_INET6 packets ieee802154_6lo_encode_pkt() compares the whole packet length against IEEE802154_MTU and takes the fragmentation path when it does not fit, so every buffer copied on the unfragmented branch is within bounds. It is reachable through NET_AF_PACKET sockets bound to an 802.15.4 interface: for NET_SOCK_RAW the 6LoWPAN block is skipped entirely and for NET_SOCK_DGRAM it returns early on the address-family test, leaving no length validation anywhere on the transmit path (net_context_sendto() and net_if_tx() apply none, and pkt_buffer_length() does not clamp the allocation for this L2).\n\nAn application \u2014 or, in a CONFIG_USERSPACE build, an unprivileged application thread using the zsock_socket()/zsock_sendto() syscalls \u2014 can therefore drive a supervisor-mode out-of-bounds write of chosen bytes past the 125-byte pool buffer. With the default CONFIG_NET_BUF_FIXED_DATA_SIZE of 128 bytes the overrun is bounded to roughly ll_hdr_len + 3 bytes; with CONFIG_NET_BUF_VARIABLE_DATA_SIZE a single storage buffer can be as large as CONFIG_NET_PKT_BUF_TX_DATA_POOL_SIZE, making the overrun far larger. The consequence is corruption of memory adjacent to the pool, with a crash or further compromise of kernel state as the practical impact.\n\nThe fix validates ll_hdr_len + net_pkt_get_len(pkt) + authtag_len against IEEE802154_MTU before any copy and adds a tailroom-checking copy_pkt_to_frame() helper that returns -EMSGSIZE instead of overrunning the buffer. The same change also linearizes the whole net_buf chain into one MAC frame, so packet storage boundaries no longer become frame boundaries on the wire."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/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-09-28T20:00:01.312Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/3d4c6177d2dbd77d12d9b14cd75a00cdbd826227"
},
{
"name": "GHSA-j76j-jrjc-xgvp",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j76j-jrjc-xgvp"
}
],
"title": "Out-of-bounds write in the IEEE 802.15.4 L2 transmit path for oversized non-6LoWPAN frames",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18415",
"datePublished": "2026-09-28T20:00:01.312Z",
"dateReserved": "2026-07-30T17:54:11.604Z",
"dateUpdated": "2026-09-30T15:28:20.759Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18414 (GCVE-0-2026-18414)
Vulnerability from nvd – Published: 2026-09-28 20:00 – Updated: 2026-09-30 15:28
VLAI
EPSS
VEX
Title
Out-of-bounds write in the ADI MAX32 ADC driver due to incorrect adc_sequence buffer size validation
Summary
The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that "the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough". The ADI MAX32 driver did not honour that contract. start_read() in drivers/adc/adc_max32.c compared buffer_size, a byte count, against a sample count ((1 + extra_samplings) channels), ignoring sizeof(uint16_t), so it accepted a buffer half the required size. The samples are then stored through the uint16_t data->buffer by Wrap_MXC_ADC_GetData(), which writes two bytes per sample and advances the pointer by one uint16_t: in adc_max32_start_channel() for synchronous reads, and in adc_max32_isr() for asynchronous ones. A sequence selecting two channels with a two-byte buffer, for example, passes the check and has its second sample written past the end of the buffer.
On a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options->callback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to a MAX32 ADC device object therefore fully controls channels, buffer, buffer_size and options->extra_samplings, and can make the driver write twice as many bytes as its buffer holds. Because the check scales with extra_samplings, the overrun equals the length of the buffer itself, up to channels * 65536 bytes past its end, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.
The resulting stores are performed by the driver in kernel mode (in the system call itself, the ADC context timer, or the ADC interrupt handler for asynchronous reads), where the MPU does not restrict the thread's memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.
The fix replaces that check in start_read() with a call to the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c, passing sizeof(uint16_t) as the sample size. The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 15:19 UTC
CWE
- CWE-787 - bounds
Assigner
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-18414",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T15:19:10.980710Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T15:28:20.886Z",
"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_common.c",
"drivers/adc/adc_common.h",
"drivers/adc/adc_max32.c",
"drivers/adc/adc_mcux_lpadc.c"
],
"programRoutines": [
{
"name": "adc_max32_isr"
},
{
"name": "adc_max32_start_channel"
},
{
"name": "start_read"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.0.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that \"the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough\". The ADI MAX32 driver did not honour that contract. start_read() in drivers/adc/adc_max32.c compared buffer_size, a byte count, against a sample count ((1 + extra_samplings) channels), ignoring sizeof(uint16_t), so it accepted a buffer half the required size. The samples are then stored through the uint16_t data-\u003ebuffer by Wrap_MXC_ADC_GetData(), which writes two bytes per sample and advances the pointer by one uint16_t: in adc_max32_start_channel() for synchronous reads, and in adc_max32_isr() for asynchronous ones. A sequence selecting two channels with a two-byte buffer, for example, passes the check and has its second sample written past the end of the buffer.\n\nOn a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options-\u003ecallback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to a MAX32 ADC device object therefore fully controls channels, buffer, buffer_size and options-\u003eextra_samplings, and can make the driver write twice as many bytes as its buffer holds. Because the check scales with extra_samplings, the overrun equals the length of the buffer itself, up to channels * 65536 bytes past its end, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.\n\nThe resulting stores are performed by the driver in kernel mode (in the system call itself, the ADC context timer, or the ADC interrupt handler for asynchronous reads), where the MPU does not restrict the thread\u0027s memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.\n\nThe fix replaces that check in start_read() with a call to the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c, passing sizeof(uint16_t) as the sample size. The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started."
}
],
"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-09-28T20:00:00.133Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit 9338c518bf2b",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/9338c518bf2b6a396f166d4dbe9985ce7e44379c"
},
{
"name": "Fix commit 3bda971a52dd",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/3bda971a52ddbbec28f6fcfe3b006d34e8b9e5a9"
},
{
"name": "GHSA-ghm4-78mm-8v2c",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-ghm4-78mm-8v2c"
}
],
"title": "Out-of-bounds write in the ADI MAX32 ADC driver due to incorrect adc_sequence buffer size validation",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18414",
"datePublished": "2026-09-28T20:00:00.133Z",
"dateReserved": "2026-07-30T17:54:10.376Z",
"dateUpdated": "2026-09-30T15:28:20.886Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18413 (GCVE-0-2026-18413)
Vulnerability from nvd – Published: 2026-09-28 19:59 – Updated: 2026-09-30 20:11
VLAI
EPSS
VEX
Title
Out-of-bounds write in the NXP MCUX LPADC ADC driver due to missing adc_sequence buffer size validation
Summary
The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that "the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough". The NXP MCUX LPADC driver did not honour that contract. mcux_lpadc_start_read() in drivers/adc/adc_mcux_lpadc.c performed no buffer-size check at all before assigning data->buffer = sequence->buffer. Each completed conversion then stores one 16-bit sample per enabled channel per sampling round through an unbounded *data->buffer++: in mcux_lpadc_isr() for interrupt-driven builds, and in mcux_lpadc_dma_callback() for DMA-driven builds on releases that have the DMA path. A sequence selecting two channels with a two-byte buffer, for example, has its second sample written past the end of the buffer.
On a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options->callback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to an LPADC device object therefore fully controls channels, buffer, buffer_size and options->extra_samplings, and can request far more samples than its buffer can hold: up to channels * 65536 samples into a two-byte buffer, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.
The resulting stores are performed by the driver in kernel mode (in the ADC interrupt handler or the DMA completion callback), where the MPU does not restrict the thread's memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.
The fix calls the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c from mcux_lpadc_start_read(). The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 19:45 UTC
CWE
- CWE-787 - bounds
Assigner
References
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
2.5.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18413",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T19:45:30.410256Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T20:11:11.842Z",
"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_common.c",
"drivers/adc/adc_common.h",
"drivers/adc/adc_max32.c",
"drivers/adc/adc_mcux_lpadc.c"
],
"programRoutines": [
{
"name": "mcux_lpadc_dma_callback"
},
{
"name": "mcux_lpadc_isr"
},
{
"name": "mcux_lpadc_start_read"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "2.5.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that \"the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough\". The NXP MCUX LPADC driver did not honour that contract. mcux_lpadc_start_read() in drivers/adc/adc_mcux_lpadc.c performed no buffer-size check at all before assigning data-\u003ebuffer = sequence-\u003ebuffer. Each completed conversion then stores one 16-bit sample per enabled channel per sampling round through an unbounded *data-\u003ebuffer++: in mcux_lpadc_isr() for interrupt-driven builds, and in mcux_lpadc_dma_callback() for DMA-driven builds on releases that have the DMA path. A sequence selecting two channels with a two-byte buffer, for example, has its second sample written past the end of the buffer.\n\nOn a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options-\u003ecallback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to an LPADC device object therefore fully controls channels, buffer, buffer_size and options-\u003eextra_samplings, and can request far more samples than its buffer can hold: up to channels * 65536 samples into a two-byte buffer, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.\n\nThe resulting stores are performed by the driver in kernel mode (in the ADC interrupt handler or the DMA completion callback), where the MPU does not restrict the thread\u0027s memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.\n\nThe fix calls the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c from mcux_lpadc_start_read(). The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started."
}
],
"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-09-28T19:59:58.873Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit 9338c518bf2b",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/9338c518bf2b6a396f166d4dbe9985ce7e44379c"
},
{
"name": "Fix commit 3bda971a52dd",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/3bda971a52ddbbec28f6fcfe3b006d34e8b9e5a9"
},
{
"name": "GHSA-7jqq-2g5q-hcrp",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-7jqq-2g5q-hcrp"
}
],
"title": "Out-of-bounds write in the NXP MCUX LPADC ADC driver due to missing adc_sequence buffer size validation",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18413",
"datePublished": "2026-09-28T19:59:58.873Z",
"dateReserved": "2026-07-30T17:54:09.140Z",
"dateUpdated": "2026-09-30T20:11:11.842Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-16513 (GCVE-0-2026-16513)
Vulnerability from nvd – Published: 2026-09-28 19:59 – Updated: 2026-09-30 20:11
VLAI
EPSS
VEX
Title
Missing write validation of user-supplied handle pointer in the RTIO syscall verifier allows arbitrary kernel write
Summary
The userspace verifier z_vrfy_rtio_sqe_copy_in_get_handles() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) validated the RTIO object handle and the sqes input array, but not the handle out-parameter. On the first loop iteration it executed *handle = sqe, storing the kernel address of the newly acquired submission-queue entry through a pointer taken verbatim from user mode, with no K_SYSCALL_MEMORY_WRITE check in front of it.
Any user-mode thread that has been granted a struct rtio kernel object can invoke the syscall with an arbitrary address in handle. That is the ordinary way an unprivileged thread uses the RTIO API, for example via sensor_read_async_mempool() or the async ADC helpers, which call rtio_sqe_copy_in_get_handles() internally. The store happens in supervisor mode before any submission-entry validation, so it fires regardless of whether the SQE contents are subsequently rejected. Only builds with CONFIG_USERSPACE and CONFIG_RTIO are affected; without CONFIG_USERSPACE the verifier is not compiled and the caller is already privileged.
The write address is fully attacker-chosen and the written value is a pointer into the caller's own RTIO ring, whose contents the caller controls (the following *sqe = sqes[i] copies an attacker-supplied struct rtio_sqe into that slot). This yields a write-what-where primitive placing a pointer to attacker-controlled data at any kernel address, sufficient to corrupt kernel function pointers, thread structures, or memory-domain partition tables, and thus to escalate from user mode to kernel mode, defeating the isolation boundary CONFIG_USERSPACE is meant to enforce. At minimum it is a reliable kernel memory-corruption and crash primitive. The reporter reproduced the write on qemu_x86: a K_USER thread changed a supervisor global from NULL to a live kernel SQE pointer.
The fix adds K_SYSCALL_MEMORY_WRITE(handle, sizeof(*handle)) (guarded by the existing optional-NULL semantics) before the loop, so the destination must lie in the calling thread's writable memory domain or the thread is terminated by K_OOPS. The neighbouring verifier z_vrfy_rtio_cqe_get_mempool_buffer(), which checked its buff/buff_len out-parameters only for read although the implementation writes through them, was hardened separately by bea93400138 ("rtio: syscalls: validate output params as writable"); that residual was materially weaker, since a read check still confines the target to the caller's own memory domain.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 19:45 UTC
CWE
- CWE-787 - memory-safety
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-16513",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T19:45:44.911882Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T20:11:11.980Z",
"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/rtio/rtio_syscalls.c"
],
"programRoutines": [
{
"name": "rtio_sqe_copy_in_get_handles"
},
{
"name": "z_vrfy_rtio_sqe_copy_in_get_handles"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The userspace verifier z_vrfy_rtio_sqe_copy_in_get_handles() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) validated the RTIO object handle and the sqes input array, but not the handle out-parameter. On the first loop iteration it executed *handle = sqe, storing the kernel address of the newly acquired submission-queue entry through a pointer taken verbatim from user mode, with no K_SYSCALL_MEMORY_WRITE check in front of it.\n\nAny user-mode thread that has been granted a struct rtio kernel object can invoke the syscall with an arbitrary address in handle. That is the ordinary way an unprivileged thread uses the RTIO API, for example via sensor_read_async_mempool() or the async ADC helpers, which call rtio_sqe_copy_in_get_handles() internally. The store happens in supervisor mode before any submission-entry validation, so it fires regardless of whether the SQE contents are subsequently rejected. Only builds with CONFIG_USERSPACE and CONFIG_RTIO are affected; without CONFIG_USERSPACE the verifier is not compiled and the caller is already privileged.\n\nThe write address is fully attacker-chosen and the written value is a pointer into the caller\u0027s own RTIO ring, whose contents the caller controls (the following *sqe = sqes[i] copies an attacker-supplied struct rtio_sqe into that slot). This yields a write-what-where primitive placing a pointer to attacker-controlled data at any kernel address, sufficient to corrupt kernel function pointers, thread structures, or memory-domain partition tables, and thus to escalate from user mode to kernel mode, defeating the isolation boundary CONFIG_USERSPACE is meant to enforce. At minimum it is a reliable kernel memory-corruption and crash primitive. The reporter reproduced the write on qemu_x86: a K_USER thread changed a supervisor global from NULL to a live kernel SQE pointer.\n\nThe fix adds K_SYSCALL_MEMORY_WRITE(handle, sizeof(*handle)) (guarded by the existing optional-NULL semantics) before the loop, so the destination must lie in the calling thread\u0027s writable memory domain or the thread is terminated by K_OOPS. The neighbouring verifier z_vrfy_rtio_cqe_get_mempool_buffer(), which checked its buff/buff_len out-parameters only for read although the implementation writes through them, was hardened separately by bea93400138 (\"rtio: syscalls: validate output params as writable\"); that residual was materially weaker, since a read check still confines the target to the caller\u0027s own memory domain."
}
],
"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-09-28T19:59:57.736Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/95c355c425763fbe5e735b9ef54dacce2c4ce21f"
},
{
"name": "GHSA-fwmc-q8qg-jcxq",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-fwmc-q8qg-jcxq"
}
],
"title": "Missing write validation of user-supplied handle pointer in the RTIO syscall verifier allows arbitrary kernel write",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-16513",
"datePublished": "2026-09-28T19:59:57.736Z",
"dateReserved": "2026-07-21T21:42:58.503Z",
"dateUpdated": "2026-09-30T20:11:11.980Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17054 (GCVE-0-2026-17054)
Vulnerability from nvd – Published: 2026-09-21 21:16 – Updated: 2026-09-22 15:51
VLAI
EPSS
VEX
Title
Out-of-bounds read and permanent loss of Wi-Fi reception in the ESP-hosted SPI driver's frame reassembly
Summary
The Espressif ESP-hosted Wi-Fi driver (drivers/wifi/esp_hosted/) parses frames received over SPI from the ESP co-processor in esp_hosted_event_task(). For control frames it took the 16-bit TLV field data_length straight off the wire and passed it to pb_istream_from_buffer(frame.data_value, frame.data_length) without checking it against the frame length or the receive buffer. frame.data_value sits 26 bytes into a 3188-byte stack object, so a data_length of up to 0xFFFF makes pb_decode() read up to roughly 62 KB past the end of that object.
Only the first fragment of a fragmented control response carries a TLV header; the pre-fix driver performed half-duplex SPI transactions and silently discarded any frame the co-processor queued while the host was transmitting (esp_hosted_hal_spi_transfer() aliased the RX buffer onto the TX buffer). When the discarded frame is the first fragment of a fragmented response, the driver treats the next fragment as a new frame — its per-fragment header and checksum are genuine, so both validation steps pass — and reads the TLV header out of raw protobuf continuation bytes. Those bytes come from control responses whose size and content an adjacent, unauthenticated attacker can influence, notably the AP scan list, which grows with the number and SSID length of access points in radio range.
The impact is denial of service rather than disclosure. Reading past the end of the RAM region faults the device, and CONFIG_NANOPB_ENABLE_MALLOC is selected by the driver, so garbage length prefixes read out of bounds also drive heap allocations. The out-of-bounds bytes themselves do not reach the application: pb_decode() is started mid-stream on raw protobuf continuation bytes and so almost always fails outright, and anything that did decode would still have to pass esp_hosted_response(), which requires an exact msg_id match against the pending request, and then esp_hosted_ctrl_response(), which requires a success resp — an attacker influences the size and content of legitimate control responses, not the structure decoded out of misaligned bytes. Two related defects in the same receive path make the denial of service permanent: the fragment reassembly guard was sized with ESP_FRAME_SIZE instead of ESP_FRAME_MAX_PAYLOAD and, when tripped, returned from the sole RX thread instead of dropping the frame, and unhandled control events were queued with k_msgq_put(..., K_FOREVER) on an eight-entry queue that nothing drains, blocking that same thread. The driver has no watchdog or restart path, so either condition ends all Wi-Fi reception until the device is rebooted.
Severity
5.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 15:51 UTC
CWE
- CWE-125 - bounds
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-17054",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T15:51:43.430440Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T15:51:55.360Z",
"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/wifi/esp_hosted/Kconfig.esp_hosted",
"drivers/wifi/esp_hosted/esp_hosted_hal.c",
"drivers/wifi/esp_hosted/esp_hosted_util.h",
"drivers/wifi/esp_hosted/esp_hosted_wifi.c",
"drivers/wifi/esp_hosted/esp_hosted_wifi.h"
],
"programRoutines": [
{
"name": "esp_hosted_event_task"
},
{
"name": "esp_hosted_hal_spi_transfer"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.2.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Espressif ESP-hosted Wi-Fi driver (drivers/wifi/esp_hosted/) parses frames received over SPI from the ESP co-processor in esp_hosted_event_task(). For control frames it took the 16-bit TLV field data_length straight off the wire and passed it to pb_istream_from_buffer(frame.data_value, frame.data_length) without checking it against the frame length or the receive buffer. frame.data_value sits 26 bytes into a 3188-byte stack object, so a data_length of up to 0xFFFF makes pb_decode() read up to roughly 62 KB past the end of that object.\n\nOnly the first fragment of a fragmented control response carries a TLV header; the pre-fix driver performed half-duplex SPI transactions and silently discarded any frame the co-processor queued while the host was transmitting (esp_hosted_hal_spi_transfer() aliased the RX buffer onto the TX buffer). When the discarded frame is the first fragment of a fragmented response, the driver treats the next fragment as a new frame \u2014 its per-fragment header and checksum are genuine, so both validation steps pass \u2014 and reads the TLV header out of raw protobuf continuation bytes. Those bytes come from control responses whose size and content an adjacent, unauthenticated attacker can influence, notably the AP scan list, which grows with the number and SSID length of access points in radio range.\n\nThe impact is denial of service rather than disclosure. Reading past the end of the RAM region faults the device, and CONFIG_NANOPB_ENABLE_MALLOC is selected by the driver, so garbage length prefixes read out of bounds also drive heap allocations. The out-of-bounds bytes themselves do not reach the application: pb_decode() is started mid-stream on raw protobuf continuation bytes and so almost always fails outright, and anything that did decode would still have to pass esp_hosted_response(), which requires an exact msg_id match against the pending request, and then esp_hosted_ctrl_response(), which requires a success resp \u2014 an attacker influences the size and content of legitimate control responses, not the structure decoded out of misaligned bytes. Two related defects in the same receive path make the denial of service permanent: the fragment reassembly guard was sized with ESP_FRAME_SIZE instead of ESP_FRAME_MAX_PAYLOAD and, when tripped, returned from the sole RX thread instead of dropping the frame, and unhandled control events were queued with k_msgq_put(..., K_FOREVER) on an eight-entry queue that nothing drains, blocking that same thread. The driver has no watchdog or restart path, so either condition ends all Wi-Fi reception until the device is rebooted."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T21:16:05.314Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/93c32f240c9661f321233c134cfdd07f8dc97bb8"
},
{
"name": "GHSA-mq9g-c5j9-79v5",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-mq9g-c5j9-79v5"
}
],
"title": "Out-of-bounds read and permanent loss of Wi-Fi reception in the ESP-hosted SPI driver\u0027s frame reassembly",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17054",
"datePublished": "2026-09-21T21:16:05.314Z",
"dateReserved": "2026-07-24T13:31:08.179Z",
"dateUpdated": "2026-09-22T15:51:55.360Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-15890 (GCVE-0-2026-15890)
Vulnerability from nvd – Published: 2026-09-21 21:16 – Updated: 2026-09-22 15:50
VLAI
EPSS
VEX
Title
AEAD nonce reuse in Zephyr secure_storage ITS default nonce provider due to missing thread synchronization
Summary
The default AEAD nonce provider for the PSA Internal Trusted Storage transform module, secure_storage_its_transform_aead_get_nonce() in subsys/secure_storage/src/its/transform/aead_get.c, stores its nonce counter in unsynchronized function-local static variables (s_nonce and s_nonce_initialized). Every ITS write obtains its AES-GCM or ChaCha20-Poly1305 nonce here via secure_storage_its_transform_to_store().
Because the function held no lock, two threads calling it concurrently race on the shared statics: the initialization path (psa_generate_random() followed by memcpy()) and the non-atomic increment-then-copy path can each hand the same nonce value to two distinct encryption operations, and can lose increments so the counter repeats values it was designed never to repeat. The ITS layer (secure_storage_its_set() in subsys/secure_storage/src/its/implementation.c) performs no serialization of its own, so concurrent same-UID writes reach the racy provider directly.
Reusing a nonce with the same key under AES-GCM or ChaCha20-Poly1305 is a catastrophic AEAD failure: it leaks the XOR of the two plaintexts (ITS routinely stores secrets, including PSA persistent keys) and, for GCM, exposes the authentication key, enabling forgery of stored entries. Because the AEAD key is derived per entry UID, the security-relevant collision is two concurrent writes to the same UID both receiving the same nonce; an adversary able to read the raw backing storage can then exploit the reuse.
Both ITS store back-ends shipped with Zephyr, zms.c and the settings/NVS back-end in settings.c, are log-structured flash stores with deferred garbage collection, so an entry superseded by a rewrite remains physically present in the partition until its sector is reclaimed. Two same-UID writes that race therefore leave both ciphertexts readable in the raw image at once, which is the condition the nonce reuse needs to be exploitable. The trigger remains narrow: both built-in key providers (DEVICE_ID_HASH and ENTRY_UID_HASH) salt the derived key with the entry UID, so reuse across different UIDs is harmless, and the exposure requires an application that writes the same UID concurrently from two threads.
The fix serializes the provider with a K_MUTEX_DEFINE(s_nonce_mutex) held for the duration of nonce generation.
Severity
5.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 15:50 UTC
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.0.0 , < 4.3.2
(semver)
Affected: 4.4.0 , < 4.4.2 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-15890",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T15:50:50.587244Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T15:50:59.284Z",
"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/secure_storage/src/its/transform/aead_get.c"
],
"programRoutines": [
{
"name": "secure_storage_its_transform_aead_get_nonce"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.3.2",
"status": "affected",
"version": "4.0.0",
"versionType": "semver"
},
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The default AEAD nonce provider for the PSA Internal Trusted Storage transform module, secure_storage_its_transform_aead_get_nonce() in subsys/secure_storage/src/its/transform/aead_get.c, stores its nonce counter in unsynchronized function-local static variables (s_nonce and s_nonce_initialized). Every ITS write obtains its AES-GCM or ChaCha20-Poly1305 nonce here via secure_storage_its_transform_to_store().\n\nBecause the function held no lock, two threads calling it concurrently race on the shared statics: the initialization path (psa_generate_random() followed by memcpy()) and the non-atomic increment-then-copy path can each hand the same nonce value to two distinct encryption operations, and can lose increments so the counter repeats values it was designed never to repeat. The ITS layer (secure_storage_its_set() in subsys/secure_storage/src/its/implementation.c) performs no serialization of its own, so concurrent same-UID writes reach the racy provider directly.\n\nReusing a nonce with the same key under AES-GCM or ChaCha20-Poly1305 is a catastrophic AEAD failure: it leaks the XOR of the two plaintexts (ITS routinely stores secrets, including PSA persistent keys) and, for GCM, exposes the authentication key, enabling forgery of stored entries. Because the AEAD key is derived per entry UID, the security-relevant collision is two concurrent writes to the same UID both receiving the same nonce; an adversary able to read the raw backing storage can then exploit the reuse.\n\nBoth ITS store back-ends shipped with Zephyr, zms.c and the settings/NVS back-end in settings.c, are log-structured flash stores with deferred garbage collection, so an entry superseded by a rewrite remains physically present in the partition until its sector is reclaimed. Two same-UID writes that race therefore leave both ciphertexts readable in the raw image at once, which is the condition the nonce reuse needs to be exploitable. The trigger remains narrow: both built-in key providers (DEVICE_ID_HASH and ENTRY_UID_HASH) salt the derived key with the entry UID, so reuse across different UIDs is harmless, and the exposure requires an application that writes the same UID concurrently from two threads.\n\nThe fix serializes the provider with a K_MUTEX_DEFINE(s_nonce_mutex) held for the duration of nonce generation."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-323",
"description": "crypto",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-362",
"description": "crypto",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T21:16:04.169Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/dc66397309248271df1fd0131d68ce8ea62bf91b"
},
{
"name": "GHSA-23jw-7xv2-xr28",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-23jw-7xv2-xr28"
}
],
"title": "AEAD nonce reuse in Zephyr secure_storage ITS default nonce provider due to missing thread synchronization",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-15890",
"datePublished": "2026-09-21T21:16:04.169Z",
"dateReserved": "2026-07-15T17:38:06.560Z",
"dateUpdated": "2026-09-22T15:50:59.284Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17052 (GCVE-0-2026-17052)
Vulnerability from nvd – Published: 2026-09-21 18:35 – Updated: 2026-09-21 18:43
VLAI
EPSS
VEX
Title
Missing user-pointer validation in tgpio_pin_read_ts_ec syscall handler allows arbitrary supervisor-memory write from userspace
Summary
The Time-aware GPIO syscall verification handler z_vrfy_tgpio_pin_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_handlers.c validated only the port device object and passed the caller-supplied timestamp and event_count output pointers to the driver without a K_SYSCALL_MEMORY_WRITE() check. The other handlers in the same file (z_vrfy_tgpio_port_get_time(), z_vrfy_tgpio_port_get_cycles_per_second()) already performed that check, so the omission left one syscall unguarded.
tgpio_pin_read_ts_ec() is declared __syscall, so with CONFIG_USERSPACE=y an unprivileged user-mode thread that has been granted access to the TGPIO device object can invoke it with arbitrary pointer values. tgpio_intel_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_intel.c bounds-checks only the pin index and then unconditionally performs timestamp = ... and event_count = ..., executing two 8-byte stores in supervisor mode at addresses chosen by the user-mode caller.
The result is a write-what-where primitive that crosses the userspace/kernel boundary: the target address is fully attacker-chosen and the stored values are the hardware time-capture and event-counter register contents. Corrupting kernel data structures this way can escalate the calling thread to supervisor privilege or crash the system; the device-object permission required is a narrow capability that is not intended to confer any kernel-memory access. The fix adds the two missing K_SYSCALL_MEMORY_WRITE() validations before the driver call.
Exposure is narrow in practice. Only builds with CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y compile the affected file, and from v3.6.0 onward the file additionally referenced a relocated header (<zephyr/syscall_handler.h>) and removed Z_SYSCALL_* macros, so such a configuration failed to build until those were repaired after v4.4.0. Downstream trees that locally corrected that breakage, and v3.5.0 builds where it did not exist, are the exposed population.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-21 18:42 UTC
CWE
- CWE-787 - memory-safety
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-17052",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-21T18:42:55.294194Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T18:43:05.834Z",
"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/timeaware_gpio/timeaware_gpio_handlers.c"
],
"programRoutines": [
{
"name": "tgpio_intel_read_ts_ec"
},
{
"name": "tgpio_pin_read_ts_ec"
},
{
"name": "z_vrfy_tgpio_pin_read_ts_ec"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.5.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Time-aware GPIO syscall verification handler z_vrfy_tgpio_pin_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_handlers.c validated only the port device object and passed the caller-supplied timestamp and event_count output pointers to the driver without a K_SYSCALL_MEMORY_WRITE() check. The other handlers in the same file (z_vrfy_tgpio_port_get_time(), z_vrfy_tgpio_port_get_cycles_per_second()) already performed that check, so the omission left one syscall unguarded.\n\ntgpio_pin_read_ts_ec() is declared __syscall, so with CONFIG_USERSPACE=y an unprivileged user-mode thread that has been granted access to the TGPIO device object can invoke it with arbitrary pointer values. tgpio_intel_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_intel.c bounds-checks only the pin index and then unconditionally performs timestamp = ... and event_count = ..., executing two 8-byte stores in supervisor mode at addresses chosen by the user-mode caller.\n\nThe result is a write-what-where primitive that crosses the userspace/kernel boundary: the target address is fully attacker-chosen and the stored values are the hardware time-capture and event-counter register contents. Corrupting kernel data structures this way can escalate the calling thread to supervisor privilege or crash the system; the device-object permission required is a narrow capability that is not intended to confer any kernel-memory access. The fix adds the two missing K_SYSCALL_MEMORY_WRITE() validations before the driver call.\n\nExposure is narrow in practice. Only builds with CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y compile the affected file, and from v3.6.0 onward the file additionally referenced a relocated header (\u003czephyr/syscall_handler.h\u003e) and removed Z_SYSCALL_* macros, so such a configuration failed to build until those were repaired after v4.4.0. Downstream trees that locally corrected that breakage, and v3.5.0 builds where it did not exist, are the exposed population."
}
],
"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-09-21T18:35:30.081Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/26264fffc17c2174319394ffa274af3f6efdc221"
},
{
"name": "GHSA-8qw6-x76h-8mpc",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8qw6-x76h-8mpc"
}
],
"title": "Missing user-pointer validation in tgpio_pin_read_ts_ec syscall handler allows arbitrary supervisor-memory write from userspace",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17052",
"datePublished": "2026-09-21T18:35:30.081Z",
"dateReserved": "2026-07-24T13:31:05.682Z",
"dateUpdated": "2026-09-21T18:43:05.834Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17051 (GCVE-0-2026-17051)
Vulnerability from nvd – Published: 2026-09-21 16:41 – Updated: 2026-09-21 18:48
VLAI
EPSS
VEX
Title
Out-of-bounds write in the Intel SEDI IPM driver from an unvalidated inbound doorbell length
Summary
The Intel SEDI IPM (inter-processor mailbox) driver in drivers/ipm/ipm_sedi.c handles an inbound message interrupt in ipm_event_dispose(). It read the peer-written doorbell register, extracted the payload length with IPC_HEADER_GET_LENGTH(), and passed that length straight to sedi_ipc_read_msg() to copy the message into struct ipm_sedi_context.incoming_data_buf, without checking it against the buffer size. The doorbell length field is 10 bits wide (IPC_HEADER_LENGTH_MASK is 0x03FF), so it can encode up to 1023 bytes, while incoming_data_buf is IPC_DATA_LEN_MAX (128) bytes. The bounds check in the underlying HAL sedi_ipc_read_msg() is a DBG_CHECK that compiles away unless CONFIG_DEBUG is set, so no check remained in a production image.
The doorbell register is written by the peer processor on the other side of the IPC link — for the intel_ish_5_* targets, the host CPU's ISH driver, reached through the device's memory-mapped register window. Host-side software with driver-level or raw BAR access can therefore set a length of up to 1023 and cause the interrupt handler to copy far past the destination buffer. The affected path requires an application to have registered an IPM receive callback via ipm_register_callback(), which is the driver's normal mode of use.
The result is an out-of-bounds write of up to 895 bytes into static (.bss) memory, performed in interrupt context. The overflow first clobbers the rest of struct ipm_sedi_context — including the k_sem and k_mutex used by the transmit path, whose wait queues contain self-referential list pointers — and then adjacent static data, giving a kernel data-structure corruption and crash primitive. The overflowing bytes are read from registers following the message window, a portion of which are themselves peer-programmable. The fix rejects any doorbell whose encoded length exceeds IPC_DATA_LEN_MAX, logging it and acknowledging the doorbell so the peer is not left waiting.
Severity
6 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-21 18:48 UTC
CWE
- CWE-787 - bounds
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-17051",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-21T18:48:41.746593Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T18:48:52.333Z",
"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/ipm/ipm_sedi.c"
],
"programRoutines": [
{
"name": "ipm_event_dispose"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.5.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Intel SEDI IPM (inter-processor mailbox) driver in drivers/ipm/ipm_sedi.c handles an inbound message interrupt in ipm_event_dispose(). It read the peer-written doorbell register, extracted the payload length with IPC_HEADER_GET_LENGTH(), and passed that length straight to sedi_ipc_read_msg() to copy the message into struct ipm_sedi_context.incoming_data_buf, without checking it against the buffer size. The doorbell length field is 10 bits wide (IPC_HEADER_LENGTH_MASK is 0x03FF), so it can encode up to 1023 bytes, while incoming_data_buf is IPC_DATA_LEN_MAX (128) bytes. The bounds check in the underlying HAL sedi_ipc_read_msg() is a DBG_CHECK that compiles away unless CONFIG_DEBUG is set, so no check remained in a production image.\n\nThe doorbell register is written by the peer processor on the other side of the IPC link \u2014 for the intel_ish_5_* targets, the host CPU\u0027s ISH driver, reached through the device\u0027s memory-mapped register window. Host-side software with driver-level or raw BAR access can therefore set a length of up to 1023 and cause the interrupt handler to copy far past the destination buffer. The affected path requires an application to have registered an IPM receive callback via ipm_register_callback(), which is the driver\u0027s normal mode of use.\n\nThe result is an out-of-bounds write of up to 895 bytes into static (.bss) memory, performed in interrupt context. The overflow first clobbers the rest of struct ipm_sedi_context \u2014 including the k_sem and k_mutex used by the transmit path, whose wait queues contain self-referential list pointers \u2014 and then adjacent static data, giving a kernel data-structure corruption and crash primitive. The overflowing bytes are read from registers following the message window, a portion of which are themselves peer-programmable. The fix rejects any doorbell whose encoded length exceeds IPC_DATA_LEN_MAX, logging it and acknowledging the doorbell so the peer is not left waiting."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:H/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-09-21T16:41:24.528Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/74c7d27925055e8c3c8aef7a9f16cae6a8c64b70"
},
{
"name": "GHSA-78p3-4gv3-qjh9",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-78p3-4gv3-qjh9"
}
],
"title": "Out-of-bounds write in the Intel SEDI IPM driver from an unvalidated inbound doorbell length",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17051",
"datePublished": "2026-09-21T16:41:24.528Z",
"dateReserved": "2026-07-24T13:31:04.469Z",
"dateUpdated": "2026-09-21T18:48:52.333Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17050 (GCVE-0-2026-17050)
Vulnerability from nvd – Published: 2026-09-21 16:41 – Updated: 2026-09-21 18:49
VLAI
EPSS
VEX
Title
Double free of the USB host configuration descriptor when device enumeration fails
Summary
The experimental USB host stack allocates a per-device configuration-descriptor buffer, udev->cfg_desc, from the dedicated usb_device_heap in usbh_device_set_configuration() (subsys/usb/host/usbh_device.c). On three failure paths — a failed full-length GET_DESCRIPTOR(CONFIGURATION) read, a mismatch between the short and full descriptor reads, and a rejected descriptor in parse_configuration_descriptor() — the buffer was released with k_heap_free() but the pointer was left dangling. The cleanup in usbh_device_free() is guarded only by if (udev->cfg_desc != NULL), so it frees the same block a second time.
The path is driven entirely by the attached peripheral: usbh_device_connect() calls usbh_device_init(), which ends in usbh_device_set_configuration(), and on failure usbh_device_connect() calls usbh_device_free(). On v4.4.x this happens during the same enumeration, with no unplug required; on v4.1.0–v4.3.x the second free instead arrives via dev_removed_handler()/dev_connected_handler() in subsys/usb/host/usbh_core.c, so it requires a removal or duplicate-connect event after the failed enumeration — a sequence the attached device fully controls. A malicious or malformed USB device only has to answer the first 9-byte configuration-descriptor request with a well-formed header and then fail any of the three checks, for example by returning a full descriptor whose interface count disagrees with bNumInterfaces, or by answering the second read with different bytes.
The result is a double free on usb_device_heap. On builds where lib/heap hardening is active (the current default CONFIG_SYS_HEAP_HARDENING_BASIC), sys_heap_free() detects the already-free chunk and calls k_panic(), giving a deterministic, peripheral-triggered denial of service of the USB host. On builds without that detection — earlier releases, or CONFIG_SYS_HEAP_HARDENING_NONE — the second free manipulates a chunk already on the free list, corrupting the heap's free list so that later allocations can return overlapping or invalid blocks.
Exploitation beyond denial of service is bounded by the fact that usb_device_heap is a small dedicated heap (CONFIG_USBH_USB_DEVICE_HEAP, default 1024 bytes) whose only client is this descriptor buffer, and by CONFIG_USB_HOST_STACK being marked experimental and disabled by default. The fix sets udev->cfg_desc = NULL after every k_heap_free(), making the cleanup guard sound.
Severity
5.7 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-21 18:49 UTC
CWE
- CWE-415 - use-after-free
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.1.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-17050",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-21T18:49:15.331848Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T18:49:25.187Z",
"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/usb/host/usbh_device.c"
],
"programRoutines": [
{
"name": "usbh_device_free"
},
{
"name": "usbh_device_set_configuration"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The experimental USB host stack allocates a per-device configuration-descriptor buffer, udev-\u003ecfg_desc, from the dedicated usb_device_heap in usbh_device_set_configuration() (subsys/usb/host/usbh_device.c). On three failure paths \u2014 a failed full-length GET_DESCRIPTOR(CONFIGURATION) read, a mismatch between the short and full descriptor reads, and a rejected descriptor in parse_configuration_descriptor() \u2014 the buffer was released with k_heap_free() but the pointer was left dangling. The cleanup in usbh_device_free() is guarded only by if (udev-\u003ecfg_desc != NULL), so it frees the same block a second time.\n\nThe path is driven entirely by the attached peripheral: usbh_device_connect() calls usbh_device_init(), which ends in usbh_device_set_configuration(), and on failure usbh_device_connect() calls usbh_device_free(). On v4.4.x this happens during the same enumeration, with no unplug required; on v4.1.0\u2013v4.3.x the second free instead arrives via dev_removed_handler()/dev_connected_handler() in subsys/usb/host/usbh_core.c, so it requires a removal or duplicate-connect event after the failed enumeration \u2014 a sequence the attached device fully controls. A malicious or malformed USB device only has to answer the first 9-byte configuration-descriptor request with a well-formed header and then fail any of the three checks, for example by returning a full descriptor whose interface count disagrees with bNumInterfaces, or by answering the second read with different bytes.\n\nThe result is a double free on usb_device_heap. On builds where lib/heap hardening is active (the current default CONFIG_SYS_HEAP_HARDENING_BASIC), sys_heap_free() detects the already-free chunk and calls k_panic(), giving a deterministic, peripheral-triggered denial of service of the USB host. On builds without that detection \u2014 earlier releases, or CONFIG_SYS_HEAP_HARDENING_NONE \u2014 the second free manipulates a chunk already on the free list, corrupting the heap\u0027s free list so that later allocations can return overlapping or invalid blocks.\n\nExploitation beyond denial of service is bounded by the fact that usb_device_heap is a small dedicated heap (CONFIG_USBH_USB_DEVICE_HEAP, default 1024 bytes) whose only client is this descriptor buffer, and by CONFIG_USB_HOST_STACK being marked experimental and disabled by default. The fix sets udev-\u003ecfg_desc = NULL after every k_heap_free(), making the cleanup guard sound."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.7,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-415",
"description": "use-after-free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T16:41:23.472Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/d46a8c1f8fb65e1f80b44bd651a6dafea747602e"
},
{
"name": "GHSA-r7xw-9jhg-88cm",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-r7xw-9jhg-88cm"
}
],
"title": "Double free of the USB host configuration descriptor when device enumeration fails",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17050",
"datePublished": "2026-09-21T16:41:23.472Z",
"dateReserved": "2026-07-24T13:31:03.256Z",
"dateUpdated": "2026-09-21T18:49:25.187Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-16515 (GCVE-0-2026-16515)
Vulnerability from nvd – Published: 2026-09-18 14:30 – Updated: 2026-09-18 16:26
VLAI
EPSS
VEX
Title
ICMPv6 error messages sent for multicast-destined packets and non-unique source addresses enable network amplification in Zephyr's IPv6 stack
Summary
net_icmpv6_send_error() in subsys/net/ip/icmpv6.c implemented only one of the three RFC 4443 section 2.4 suppression rules (do not answer an ICMPv6 error with an ICMPv6 error). It did not check whether the triggering packet's source address identifies a single node (rule e.6) or whether the packet was sent to a multicast destination (rule e.3, whose only exceptions are Packet Too Big and Parameter Problem Code 2). Of the five call sites, only the port-unreachable path in subsys/net/ip/connection.c carried an equivalent guard of its own; the extension-header, unknown-next-header and fragmentation paths in subsys/net/ip/ipv6.c and subsys/net/ip/ipv6_fragment.c had none.
An unauthenticated attacker with access to the same link can exploit this in two ways. Sending a single IPv6 packet to the link-local all-nodes group ff02::1 carrying an unrecognized next-header value, with the source address spoofed to a chosen victim, causes every Zephyr node on the link to emit an ICMPv6 Parameter Problem message to that victim — a reflector with an amplification factor equal to the number of nodes. Alternatively, sending a unicast packet whose source address is a multicast address causes the node to transmit its ICMPv6 error to that multicast address, turning one unicast packet into a link-flooded multicast frame. Packets addressed to ff02::1 are accepted unconditionally by ipv6_input(), and no check rejects a multicast source address, so no special configuration is required.
The impact is degraded availability of the shared link and of the reflection victim, together with the ability for the attacker to hide its own address behind the responding nodes. The effect is amplified on constrained mesh links such as 802.15.4/Thread, where link-local multicast is flooded hop by hop. There is no memory-safety consequence: the error packet itself is well formed, it is simply emitted in cases where the protocol forbids it.
The fix adds both suppression checks at the single choke point in net_icmpv6_send_error(), before any reply packet is allocated, preserving the RFC-mandated exceptions for NET_ICMPV6_PACKET_TOO_BIG and Parameter Problem Code 2. Note that the IPv4 counterpart net_icmpv4_send_error() in subsys/net/ip/icmpv4.c still checks only for a broadcast destination and retains an equivalent gap for multicast destinations and non-unique sources.
Severity
4.7 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-18 16:25 UTC
CWE
- CWE-406 - dos
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
1.14.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-16515",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-18T16:25:27.449454Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-18T16:26:05.219Z",
"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/icmpv6.c"
],
"programRoutines": [
{
"name": "net_icmpv6_send_error"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "1.14.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "net_icmpv6_send_error() in subsys/net/ip/icmpv6.c implemented only one of the three RFC 4443 section 2.4 suppression rules (do not answer an ICMPv6 error with an ICMPv6 error). It did not check whether the triggering packet\u0027s source address identifies a single node (rule e.6) or whether the packet was sent to a multicast destination (rule e.3, whose only exceptions are Packet Too Big and Parameter Problem Code 2). Of the five call sites, only the port-unreachable path in subsys/net/ip/connection.c carried an equivalent guard of its own; the extension-header, unknown-next-header and fragmentation paths in subsys/net/ip/ipv6.c and subsys/net/ip/ipv6_fragment.c had none.\n\nAn unauthenticated attacker with access to the same link can exploit this in two ways. Sending a single IPv6 packet to the link-local all-nodes group ff02::1 carrying an unrecognized next-header value, with the source address spoofed to a chosen victim, causes every Zephyr node on the link to emit an ICMPv6 Parameter Problem message to that victim \u2014 a reflector with an amplification factor equal to the number of nodes. Alternatively, sending a unicast packet whose source address is a multicast address causes the node to transmit its ICMPv6 error to that multicast address, turning one unicast packet into a link-flooded multicast frame. Packets addressed to ff02::1 are accepted unconditionally by ipv6_input(), and no check rejects a multicast source address, so no special configuration is required.\n\nThe impact is degraded availability of the shared link and of the reflection victim, together with the ability for the attacker to hide its own address behind the responding nodes. The effect is amplified on constrained mesh links such as 802.15.4/Thread, where link-local multicast is flooded hop by hop. There is no memory-safety consequence: the error packet itself is well formed, it is simply emitted in cases where the protocol forbids it.\n\nThe fix adds both suppression checks at the single choke point in net_icmpv6_send_error(), before any reply packet is allocated, preserving the RFC-mandated exceptions for NET_ICMPV6_PACKET_TOO_BIG and Parameter Problem Code 2. Note that the IPv4 counterpart net_icmpv4_send_error() in subsys/net/ip/icmpv4.c still checks only for a broadcast destination and retains an equivalent gap for multicast destinations and non-unique sources."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 4.7,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-406",
"description": "dos",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-18T14:30:13.017Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/ba4247b24ddd3a5360b617e3ca17131ca9e8026a"
},
{
"name": "GHSA-v5vw-m78m-h46g",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-v5vw-m78m-h46g"
}
],
"title": "ICMPv6 error messages sent for multicast-destined packets and non-unique source addresses enable network amplification in Zephyr\u0027s IPv6 stack",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-16515",
"datePublished": "2026-09-18T14:30:13.017Z",
"dateReserved": "2026-07-21T21:43:00.776Z",
"dateUpdated": "2026-09-18T16:26:05.219Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-16514 (GCVE-0-2026-16514)
Vulnerability from nvd – Published: 2026-09-18 14:30 – Updated: 2026-09-18 16:42
VLAI
EPSS
VEX
Title
Out-of-bounds read in gPTP Announce path-trace validation via unvalidated stepsRemoved
Summary
gptp_mi_qualify_announce() in subsys/net/l2/ethernet/gptp/gptp_mi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce->steps_removed (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because path_sequence is the flexible member of the wire TLV (struct gptp_path_trace_tlv) and GPTP_ANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame.
The stack's only length validation, GPTP_ANNOUNCE_CHECK_LEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes — so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with steps_removed = 254; the frame passes the length check and reception path (net_gptp_recv() → gptp_handle_msg() → gptp_mi_qualify_announce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each — about 2 KB — beyond the end of the network buffer.
The impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIG_NET_GPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed.
The fix computes the true entry count as tlv.len / GPTP_CLOCK_ID_LEN and rejects the announce when steps_removed + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.
Severity
4.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-18 16:41 UTC
CWE
- CWE-125 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
1.13.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-16514",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-18T16:41:50.328879Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-18T16:42:41.192Z",
"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/gptp/gptp_mi.c"
],
"programRoutines": [
{
"name": "gptp_mi_qualify_announce"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "1.13.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "gptp_mi_qualify_announce() in subsys/net/l2/ethernet/gptp/gptp_mi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce-\u003esteps_removed (accepted up to 254), never from announce-\u003etlv.len, which is the field that states how many identities the TLV actually carries. Because path_sequence is the flexible member of the wire TLV (struct gptp_path_trace_tlv) and GPTP_ANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame.\n\nThe stack\u0027s only length validation, GPTP_ANNOUNCE_CHECK_LEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes \u2014 so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with steps_removed = 254; the frame passes the length check and reception path (net_gptp_recv() \u2192 gptp_handle_msg() \u2192 gptp_mi_qualify_announce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each \u2014 about 2 KB \u2014 beyond the end of the network buffer.\n\nThe impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIG_NET_GPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed.\n\nThe fix computes the true entry count as tlv.len / GPTP_CLOCK_ID_LEN and rejects the announce when steps_removed + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 4.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-18T14:30:11.895Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/a2c882db7a57cf08a06b4d27bead22b07a9c3c61"
},
{
"name": "GHSA-mgxg-89rr-6855",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-mgxg-89rr-6855"
}
],
"title": "Out-of-bounds read in gPTP Announce path-trace validation via unvalidated stepsRemoved",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-16514",
"datePublished": "2026-09-18T14:30:11.895Z",
"dateReserved": "2026-07-21T21:42:59.661Z",
"dateUpdated": "2026-09-18T16:42:41.192Z",
"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"
}
CVE-2026-18747 (GCVE-0-2026-18747)
Vulnerability from cvelistv5 – Published: 2026-09-28 23:25 – Updated: 2026-09-30 13:44
VLAI
EPSS
VEX
Title
Integer underflow of net_buf length in the MCUmgr serial (SMP over console) transport leads to out-of-bounds read
Summary
The MCUmgr SMP-over-console transport decodes a base64 frame, reads a 16-bit packet length from it, verifies a CRC and then unconditionally strips the trailing CRC with rx_ctxt->nb->len -= 2U; in mcumgr_serial_process_frag() (subsys/mgmt/mcumgr/transport/src/serial_util.c). mcumgr_serial_extract_len() accepted any declared length, including 0 and 1, and a packet declaring length 0 passes the checksum test for free because crc16_itu_t() over zero bytes returns the zero seed. Since net_buf::len is a uint16_t, the subtraction underflows and the buffer is handed to SMP claiming roughly 65 KB of payload while its data area is only CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE bytes (default 384).
The trigger is a single unauthenticated 7-byte line on the management console — the 0x06 0x09 packet marker followed by the base64 group AAA= and a newline — delivered to any transport built on this helper: CONFIG_MCUMGR_TRANSPORT_UART (smp_uart.c) or CONFIG_MCUMGR_TRANSPORT_SHELL (smp_shell.c), both of which select MCUMGR_TRANSPORT_SERIAL_HAS_SMP_OVER_CONSOLE. No prior session state, fragmentation or credentials are required to trigger the underflow, and the malformed frame is mishandled before any command handler or command-level access control runs. The attacker only needs write access to that console, which on many boards is a USB CDC-ACM port rather than a bare UART header.
With the inflated length, smp_process_request_packet() in subsys/mgmt/mcumgr/smp/src/smp.c loses its bound: cbor_nb_reader_init() gives the CBOR decoder a ~65 KB window into a 384-byte buffer, and each request header's nh_len is checked only against the inflated length. On its own the 7-byte frame re-parses whatever stale bytes the reused pool buffer still holds, typically a replay of the previously received request followed by a parse error, without leaving the buffer. Because the transport is unauthenticated, though, the attacker also controls the frames sent before the trigger, and can stage buffer contents so that a request succeeds with an nh_len larger than the buffer; net_buf_pull(), guarded only by __ASSERT_NO_MSG, then moves the parse cursor out of bounds and the loop reads further headers and CBOR from adjacent memory. The consequence is an out-of-bounds read that can fault the MCUmgr thread (denial of service); memory disclosure is also possible, since the default-enabled os echo handler (CONFIG_MCUMGR_GRP_OS_ECHO) decodes its string inside that window and copies it into its response. There is no integrity gain beyond what the unauthenticated transport already permits.
The fix rejects any declared packet length of two bytes or fewer in mcumgr_serial_extract_len(), so the CRC-strip subtraction can no longer underflow. The identical pattern remains in the test-only loopback transport subsys/mgmt/mcumgr/transport/src/smp_dummy.c (CONFIG_MCUMGR_TRANSPORT_DUMMY), which has no external input path and therefore carries no practical exposure.
Severity
6.8 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 13:44 UTC
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-18747",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T13:44:27.727115Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T13:44:37.055Z",
"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/mcumgr/transport/src/serial_util.c"
],
"programRoutines": [
{
"name": "mcumgr_serial_extract_len"
},
{
"name": "mcumgr_serial_process_frag"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "1.11.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The MCUmgr SMP-over-console transport decodes a base64 frame, reads a 16-bit packet length from it, verifies a CRC and then unconditionally strips the trailing CRC with rx_ctxt-\u003enb-\u003elen -= 2U; in mcumgr_serial_process_frag() (subsys/mgmt/mcumgr/transport/src/serial_util.c). mcumgr_serial_extract_len() accepted any declared length, including 0 and 1, and a packet declaring length 0 passes the checksum test for free because crc16_itu_t() over zero bytes returns the zero seed. Since net_buf::len is a uint16_t, the subtraction underflows and the buffer is handed to SMP claiming roughly 65 KB of payload while its data area is only CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE bytes (default 384).\n\nThe trigger is a single unauthenticated 7-byte line on the management console \u2014 the 0x06 0x09 packet marker followed by the base64 group AAA= and a newline \u2014 delivered to any transport built on this helper: CONFIG_MCUMGR_TRANSPORT_UART (smp_uart.c) or CONFIG_MCUMGR_TRANSPORT_SHELL (smp_shell.c), both of which select MCUMGR_TRANSPORT_SERIAL_HAS_SMP_OVER_CONSOLE. No prior session state, fragmentation or credentials are required to trigger the underflow, and the malformed frame is mishandled before any command handler or command-level access control runs. The attacker only needs write access to that console, which on many boards is a USB CDC-ACM port rather than a bare UART header.\n\nWith the inflated length, smp_process_request_packet() in subsys/mgmt/mcumgr/smp/src/smp.c loses its bound: cbor_nb_reader_init() gives the CBOR decoder a ~65 KB window into a 384-byte buffer, and each request header\u0027s nh_len is checked only against the inflated length. On its own the 7-byte frame re-parses whatever stale bytes the reused pool buffer still holds, typically a replay of the previously received request followed by a parse error, without leaving the buffer. Because the transport is unauthenticated, though, the attacker also controls the frames sent before the trigger, and can stage buffer contents so that a request succeeds with an nh_len larger than the buffer; net_buf_pull(), guarded only by __ASSERT_NO_MSG, then moves the parse cursor out of bounds and the loop reads further headers and CBOR from adjacent memory. The consequence is an out-of-bounds read that can fault the MCUmgr thread (denial of service); memory disclosure is also possible, since the default-enabled os echo handler (CONFIG_MCUMGR_GRP_OS_ECHO) decodes its string inside that window and copies it into its response. There is no integrity gain beyond what the unauthenticated transport already permits.\n\nThe fix rejects any declared packet length of two bytes or fewer in mcumgr_serial_extract_len(), so the CRC-strip subtraction can no longer underflow. The identical pattern remains in the test-only loopback transport subsys/mgmt/mcumgr/transport/src/smp_dummy.c (CONFIG_MCUMGR_TRANSPORT_DUMMY), which has no external input path and therefore carries no practical exposure."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.8,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/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": "integer-overflow",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-191",
"description": "integer-overflow",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-28T23:25:26.081Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/f7fc3e779a59c68c96eaf63a6b03ac7489f5e4a5"
},
{
"name": "GHSA-g6cx-xj75-hvfw",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-g6cx-xj75-hvfw"
}
],
"title": "Integer underflow of net_buf length in the MCUmgr serial (SMP over console) transport leads to out-of-bounds read",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18747",
"datePublished": "2026-09-28T23:25:26.081Z",
"dateReserved": "2026-08-03T21:22:12.879Z",
"dateUpdated": "2026-09-30T13:44:37.055Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18746 (GCVE-0-2026-18746)
Vulnerability from cvelistv5 – Published: 2026-09-28 23:25 – Updated: 2026-09-30 13:44
VLAI
EPSS
VEX
Title
NULL pointer dereference in Zephyr LwM2M client when the CoAP Block1 context pool is exhausted
Summary
parse_write_op() in subsys/net/lib/lwm2m/lwm2m_message_handling.c handles inbound CoAP WRITE/CREATE requests that carry a Block1 option. For the first block of a transfer it called init_block_ctx() and then immediately stored the peer-selected block size with block_ctx->ctx.block_size = block_size before inspecting the return code. init_block_ctx() sets the caller's pointer to NULL and returns -ENOMEM when no entry of the static block1_contexts[] pool is free or timed out, so that store dereferences a NULL pointer.
The pool holds CONFIG_LWM2M_NUM_BLOCK1_CONTEXT entries (default 3) and an entry is only reclaimed once its transfer completes, fails, or ages past 30 seconds. A peer that reaches the client's LwM2M socket can therefore start three block-wise writes on three distinct object paths with the CoAP More bit set and leave them incomplete, then send the first block of a fourth write on a new path to reach the unguarded dereference. Reachability is gated only by the connected UDP socket's source-address filter unless CONFIG_LWM2M_DTLS_SUPPORT is enabled — which has no default — so in a NoSec deployment an on-path or address-spoofing attacker needs no credentials; the same sequence is also reachable from a bootstrap or lower-trust server, and can be hit accidentally by a legitimate server running four concurrent block transfers.
The write targets a fixed low address with a value between 0 and 7, so the consequence is a fatal memory fault (BusFault or corrupted low memory leading to a fault) rather than a usable memory-corruption primitive: the device crashes or resets. Confidentiality and integrity are not affected. The fix moves the store below the guard and validates the context pointer itself instead of the return code, so the context is only touched once it is known to be valid.
Severity
5.9 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 13:44 UTC
CWE
- CWE-476 - memory-safety
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-18746",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T13:44:03.814947Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T13:44:12.453Z",
"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/lib/lwm2m/lwm2m_message_handling.c"
],
"programRoutines": [
{
"name": "parse_write_op"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.5.0",
"status": "affected",
"version": "3.7.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "parse_write_op() in subsys/net/lib/lwm2m/lwm2m_message_handling.c handles inbound CoAP WRITE/CREATE requests that carry a Block1 option. For the first block of a transfer it called init_block_ctx() and then immediately stored the peer-selected block size with block_ctx-\u003ectx.block_size = block_size before inspecting the return code. init_block_ctx() sets the caller\u0027s pointer to NULL and returns -ENOMEM when no entry of the static block1_contexts[] pool is free or timed out, so that store dereferences a NULL pointer.\n\nThe pool holds CONFIG_LWM2M_NUM_BLOCK1_CONTEXT entries (default 3) and an entry is only reclaimed once its transfer completes, fails, or ages past 30 seconds. A peer that reaches the client\u0027s LwM2M socket can therefore start three block-wise writes on three distinct object paths with the CoAP More bit set and leave them incomplete, then send the first block of a fourth write on a new path to reach the unguarded dereference. Reachability is gated only by the connected UDP socket\u0027s source-address filter unless CONFIG_LWM2M_DTLS_SUPPORT is enabled \u2014 which has no default \u2014 so in a NoSec deployment an on-path or address-spoofing attacker needs no credentials; the same sequence is also reachable from a bootstrap or lower-trust server, and can be hit accidentally by a legitimate server running four concurrent block transfers.\n\nThe write targets a fixed low address with a value between 0 and 7, so the consequence is a fatal memory fault (BusFault or corrupted low memory leading to a fault) rather than a usable memory-corruption primitive: the device crashes or resets. Confidentiality and integrity are not affected. The fix moves the store below the guard and validates the context pointer itself instead of the return code, so the context is only touched once it is known to be valid."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/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-09-28T23:25:24.971Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/e61790f776863032925e96819f84cafc9a958b8a"
},
{
"name": "GHSA-4q9g-2mhh-m7w7",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4q9g-2mhh-m7w7"
}
],
"title": "NULL pointer dereference in Zephyr LwM2M client when the CoAP Block1 context pool is exhausted",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18746",
"datePublished": "2026-09-28T23:25:24.971Z",
"dateReserved": "2026-08-03T21:22:11.665Z",
"dateUpdated": "2026-09-30T13:44:12.453Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18417 (GCVE-0-2026-18417)
Vulnerability from cvelistv5 – Published: 2026-09-28 23:25 – Updated: 2026-09-30 13:43
VLAI
EPSS
VEX
Title
Wild pointer dereference in Zephyr BSD sockets when a TCP listening socket reports an asynchronous error
Summary
The native BSD-socket layer recorded a pending asynchronous socket error by type-punning it into struct net_context's void user_data field (ctx->user_data = INT_TO_POINTER(-status) in zsock_accepted_cb(), zsock_received_cb(), zsock_connected_cb() and zsock_close_ctx() in subsys/net/lib/sockets/sockets_inet.c), reading it back with POINTER_TO_INT(). That same field is owned by the network stack for listening TCP contexts: net_tcp_accept() stores the parent context pointer there and the TCP core passes it back to the registered accept callback. A failed accept therefore left a small integer (an errno value) where the stack expected a struct net_context .
When the network interface carrying a listening TCP socket goes down, close_tcp_conn() in subsys/net/ip/tcp.c invokes the accept callback with -ENETDOWN and the context's user_data. In v4.3.0 the callback was not disarmed afterwards, so a second interface-down event forwarded the previously stored errno to zsock_accepted_cb(), which dereferenced it as the parent context and performed several stores through it (sock_set_error()'s read-modify-write of socket_data, k_fifo_cancel_wait(&parent->recv_q)) — the crash described in the fix's commit message. v4.3.1 and v4.4.x carry a later change clearing conn->accept_cb after the error callback (269cb8823d3 on the v4.3 branch, 913fae5169425550f2364655298fceb79b320066 on main), which closes that repeat path; on those releases the poisoned cookie remains reachable only by a narrower race, a handshake completing alongside the interface-down still passing the stale cookie to k_fifo_put(&parent->accept_q, ...), and by getsockopt(SO_ERROR), which reads the field back unconditionally.
On v4.3.0 an application that keeps a listening TCP socket open across repeated link-down events is sufficient to reach the defect; the triggering condition is a network-interface state change, not attacker-supplied packet data, so the practical attacker is one able to force the link down repeatedly (for example an adjacent attacker disrupting a wireless link) or one with local/physical access. Because both the faulting address and the stored data are fixed small constants derived from the errno value, the outcome is a wild-pointer access leading to a kernel fatal error — a denial of service (device crash or reset) rather than an attacker-directed memory corruption.
The fix stores the pending error in a dedicated net_context.sock_error field and converts every producer and consumer to sock_set_error()/sock_get_error(), leaving user_data untouched. As a side effect it also stops getsockopt(SO_ERROR) — which is evaluated unconditionally — from returning the kernel address held in user_data to a userspace application.
Severity
6.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 13:43 UTC
CWE
- CWE-843 - memory-safety
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-18417",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T13:43:32.816350Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T13:43:48.703Z",
"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": [
"include/zephyr/net/net_context.h",
"subsys/net/lib/sockets/sockets_inet.c",
"subsys/net/lib/sockets/sockets_internal.h"
],
"programRoutines": [
{
"name": "close_tcp_conn"
},
{
"name": "zsock_accepted_cb"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The native BSD-socket layer recorded a pending asynchronous socket error by type-punning it into struct net_context\u0027s void user_data field (ctx-\u003euser_data = INT_TO_POINTER(-status) in zsock_accepted_cb(), zsock_received_cb(), zsock_connected_cb() and zsock_close_ctx() in subsys/net/lib/sockets/sockets_inet.c), reading it back with POINTER_TO_INT(). That same field is owned by the network stack for listening TCP contexts: net_tcp_accept() stores the parent context pointer there and the TCP core passes it back to the registered accept callback. A failed accept therefore left a small integer (an errno value) where the stack expected a struct net_context .\n\nWhen the network interface carrying a listening TCP socket goes down, close_tcp_conn() in subsys/net/ip/tcp.c invokes the accept callback with -ENETDOWN and the context\u0027s user_data. In v4.3.0 the callback was not disarmed afterwards, so a second interface-down event forwarded the previously stored errno to zsock_accepted_cb(), which dereferenced it as the parent context and performed several stores through it (sock_set_error()\u0027s read-modify-write of socket_data, k_fifo_cancel_wait(\u0026parent-\u003erecv_q)) \u2014 the crash described in the fix\u0027s commit message. v4.3.1 and v4.4.x carry a later change clearing conn-\u003eaccept_cb after the error callback (269cb8823d3 on the v4.3 branch, 913fae5169425550f2364655298fceb79b320066 on main), which closes that repeat path; on those releases the poisoned cookie remains reachable only by a narrower race, a handshake completing alongside the interface-down still passing the stale cookie to k_fifo_put(\u0026parent-\u003eaccept_q, ...), and by getsockopt(SO_ERROR), which reads the field back unconditionally.\n\nOn v4.3.0 an application that keeps a listening TCP socket open across repeated link-down events is sufficient to reach the defect; the triggering condition is a network-interface state change, not attacker-supplied packet data, so the practical attacker is one able to force the link down repeatedly (for example an adjacent attacker disrupting a wireless link) or one with local/physical access. Because both the faulting address and the stored data are fixed small constants derived from the errno value, the outcome is a wild-pointer access leading to a kernel fatal error \u2014 a denial of service (device crash or reset) rather than an attacker-directed memory corruption.\n\nThe fix stores the pending error in a dedicated net_context.sock_error field and converts every producer and consumer to sock_set_error()/sock_get_error(), leaving user_data untouched. As a side effect it also stops getsockopt(SO_ERROR) \u2014 which is evaluated unconditionally \u2014 from returning the kernel address held in user_data to a userspace application."
}
],
"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-843",
"description": "memory-safety",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-28T23:25:23.903Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/ef370a57d07637aaee8cec7b0bcebf4002ac8f54"
},
{
"name": "GHSA-p8r8-8mw8-3wf9",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-p8r8-8mw8-3wf9"
}
],
"title": "Wild pointer dereference in Zephyr BSD sockets when a TCP listening socket reports an asynchronous error",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18417",
"datePublished": "2026-09-28T23:25:23.903Z",
"dateReserved": "2026-07-30T17:54:13.939Z",
"dateUpdated": "2026-09-30T13:43:48.703Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18416 (GCVE-0-2026-18416)
Vulnerability from cvelistv5 – Published: 2026-09-28 20:00 – Updated: 2026-09-30 15:28
VLAI
EPSS
VEX
Title
Out-of-bounds read in CoAP well-known-core Uri-Query href matching (match_path_uri)
Summary
The CoAP link-format helper match_path_uri() in subsys/net/lib/coap/coap_link_format.c compares a registered resource path against the URI carried in a Uri-Query href= option. That URI is not NUL terminated, but the inner character loop advanced its index k once per path character without ever testing it against the option length len. When a registered path segment is longer than the supplied URI and the URI is a prefix of it, the loop reads uri[len] and beyond, past the end of the option value.
The path is reached from coap_well_known_core_get_len() and coap_well_known_core_get() via match_queries_resource(), i.e. by any unauthenticated GET /.well-known/core?href=/<prefix> request to a device that serves /.well-known/core (for the CoAP server subsystem, CONFIG_COAP_SERVER_WELL_KNOWN_CORE, default y) and has at least one resource that declares struct coap_core_metadata attributes.
The over-read does not reach the receive buffer. The well-known-core builders parse the query into a stack-local struct coap_option, whose value is a fixed array (value[12], or CONFIG_COAP_EXTENDED_OPTIONS_LEN_VALUE bytes) that the option bytes are copied into, so uri points into that copy. Reading past len therefore reads the unused, uninitialized tail of the array and, when the option fills it, the bytes just past it in the same stack frame. (In the ZoAP library of v1.8.0 to v1.9.x the option value was instead a pointer into the received packet, and the over-read ran past the option inside the packet buffer.)
The impact is bounded. The number of bytes read past the end is limited by the length of the resource path segment, and each additional byte is only read if it happens to equal the next path character, so in practice the over-read is one byte. It also cannot influence the response: returning a match requires the final compared index to be len - 1 or len, both in bounds, so out-of-bounds bytes only ever steer the loop to the next candidate resource. The consequence is undefined behaviour, not information disclosure and not a matching error.
The fix adds a k >= len guard at the top of the inner loop, so every uri[k] dereference is within the option value while still allowing a trailing * wildcard to match a longer path.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 15:18 UTC
CWE
- CWE-125 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
1.8.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18416",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T15:18:49.506461Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T15:28:20.615Z",
"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/lib/coap/coap_link_format.c"
],
"programRoutines": [
{
"name": "coap_well_known_core_get"
},
{
"name": "coap_well_known_core_get_len"
},
{
"name": "match_path_uri"
},
{
"name": "match_queries_resource"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "1.8.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The CoAP link-format helper match_path_uri() in subsys/net/lib/coap/coap_link_format.c compares a registered resource path against the URI carried in a Uri-Query href= option. That URI is not NUL terminated, but the inner character loop advanced its index k once per path character without ever testing it against the option length len. When a registered path segment is longer than the supplied URI and the URI is a prefix of it, the loop reads uri[len] and beyond, past the end of the option value.\n\nThe path is reached from coap_well_known_core_get_len() and coap_well_known_core_get() via match_queries_resource(), i.e. by any unauthenticated GET /.well-known/core?href=/\u003cprefix\u003e request to a device that serves /.well-known/core (for the CoAP server subsystem, CONFIG_COAP_SERVER_WELL_KNOWN_CORE, default y) and has at least one resource that declares struct coap_core_metadata attributes.\n\nThe over-read does not reach the receive buffer. The well-known-core builders parse the query into a stack-local struct coap_option, whose value is a fixed array (value[12], or CONFIG_COAP_EXTENDED_OPTIONS_LEN_VALUE bytes) that the option bytes are copied into, so uri points into that copy. Reading past len therefore reads the unused, uninitialized tail of the array and, when the option fills it, the bytes just past it in the same stack frame. (In the ZoAP library of v1.8.0 to v1.9.x the option value was instead a pointer into the received packet, and the over-read ran past the option inside the packet buffer.)\n\nThe impact is bounded. The number of bytes read past the end is limited by the length of the resource path segment, and each additional byte is only read if it happens to equal the next path character, so in practice the over-read is one byte. It also cannot influence the response: returning a match requires the final compared index to be len - 1 or len, both in bounds, so out-of-bounds bytes only ever steer the loop to the next candidate resource. The consequence is undefined behaviour, not information disclosure and not a matching error.\n\nThe fix adds a k \u003e= len guard at the top of the inner loop, so every uri[k] dereference is within the option value while still allowing a trailing * wildcard to match a longer path."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 3.7,
"baseSeverity": "LOW",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-28T20:00:02.425Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/ef5b303dc88fb5159850623a2b51b590c36fa5bc"
},
{
"name": "GHSA-m3mv-vvm4-h58g",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-m3mv-vvm4-h58g"
}
],
"title": "Out-of-bounds read in CoAP well-known-core Uri-Query href matching (match_path_uri)",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18416",
"datePublished": "2026-09-28T20:00:02.425Z",
"dateReserved": "2026-07-30T17:54:12.762Z",
"dateUpdated": "2026-09-30T15:28:20.615Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18415 (GCVE-0-2026-18415)
Vulnerability from cvelistv5 – Published: 2026-09-28 20:00 – Updated: 2026-09-30 15:28
VLAI
EPSS
VEX
Title
Out-of-bounds write in the IEEE 802.15.4 L2 transmit path for oversized non-6LoWPAN frames
Summary
ieee802154_send() in subsys/net/l2/ieee802154/ieee802154.c copies the outgoing packet into a single fixed 125-byte transmit buffer (tx_frame_buf_pool, sized IEEE802154_MTU). In builds with CONFIG_NET_L2_IEEE802154_FRAGMENT enabled (the default whenever CONFIG_NET_6LO is set), the branch taken when 6LoWPAN fragmentation is not required performed an unchecked net_buf_add_mem(frame_buf, pkt_buf->data, pkt_buf->len). The only guard was __ASSERT_NO_MSG() inside net_buf_simple_add(), which is compiled out without CONFIG_ASSERT, so an oversized packet silently overran the frame buffer.
The defect is not reachable from the radio: for NET_AF_INET6 packets ieee802154_6lo_encode_pkt() compares the whole packet length against IEEE802154_MTU and takes the fragmentation path when it does not fit, so every buffer copied on the unfragmented branch is within bounds. It is reachable through NET_AF_PACKET sockets bound to an 802.15.4 interface: for NET_SOCK_RAW the 6LoWPAN block is skipped entirely and for NET_SOCK_DGRAM it returns early on the address-family test, leaving no length validation anywhere on the transmit path (net_context_sendto() and net_if_tx() apply none, and pkt_buffer_length() does not clamp the allocation for this L2).
An application — or, in a CONFIG_USERSPACE build, an unprivileged application thread using the zsock_socket()/zsock_sendto() syscalls — can therefore drive a supervisor-mode out-of-bounds write of chosen bytes past the 125-byte pool buffer. With the default CONFIG_NET_BUF_FIXED_DATA_SIZE of 128 bytes the overrun is bounded to roughly ll_hdr_len + 3 bytes; with CONFIG_NET_BUF_VARIABLE_DATA_SIZE a single storage buffer can be as large as CONFIG_NET_PKT_BUF_TX_DATA_POOL_SIZE, making the overrun far larger. The consequence is corruption of memory adjacent to the pool, with a crash or further compromise of kernel state as the practical impact.
The fix validates ll_hdr_len + net_pkt_get_len(pkt) + authtag_len against IEEE802154_MTU before any copy and adds a tailroom-checking copy_pkt_to_frame() helper that returns -EMSGSIZE instead of overrunning the buffer. The same change also linearizes the whole net_buf chain into one MAC frame, so packet storage boundaries no longer become frame boundaries on the wire.
Severity
6.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 15:18 UTC
CWE
- CWE-787 - bounds
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
3.2.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18415",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T15:18:58.650860Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T15:28:20.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": [
"subsys/net/l2/ieee802154/ieee802154.c"
],
"programRoutines": [
{
"name": "ieee802154_send"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.2.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "ieee802154_send() in subsys/net/l2/ieee802154/ieee802154.c copies the outgoing packet into a single fixed 125-byte transmit buffer (tx_frame_buf_pool, sized IEEE802154_MTU). In builds with CONFIG_NET_L2_IEEE802154_FRAGMENT enabled (the default whenever CONFIG_NET_6LO is set), the branch taken when 6LoWPAN fragmentation is not required performed an unchecked net_buf_add_mem(frame_buf, pkt_buf-\u003edata, pkt_buf-\u003elen). The only guard was __ASSERT_NO_MSG() inside net_buf_simple_add(), which is compiled out without CONFIG_ASSERT, so an oversized packet silently overran the frame buffer.\n\nThe defect is not reachable from the radio: for NET_AF_INET6 packets ieee802154_6lo_encode_pkt() compares the whole packet length against IEEE802154_MTU and takes the fragmentation path when it does not fit, so every buffer copied on the unfragmented branch is within bounds. It is reachable through NET_AF_PACKET sockets bound to an 802.15.4 interface: for NET_SOCK_RAW the 6LoWPAN block is skipped entirely and for NET_SOCK_DGRAM it returns early on the address-family test, leaving no length validation anywhere on the transmit path (net_context_sendto() and net_if_tx() apply none, and pkt_buffer_length() does not clamp the allocation for this L2).\n\nAn application \u2014 or, in a CONFIG_USERSPACE build, an unprivileged application thread using the zsock_socket()/zsock_sendto() syscalls \u2014 can therefore drive a supervisor-mode out-of-bounds write of chosen bytes past the 125-byte pool buffer. With the default CONFIG_NET_BUF_FIXED_DATA_SIZE of 128 bytes the overrun is bounded to roughly ll_hdr_len + 3 bytes; with CONFIG_NET_BUF_VARIABLE_DATA_SIZE a single storage buffer can be as large as CONFIG_NET_PKT_BUF_TX_DATA_POOL_SIZE, making the overrun far larger. The consequence is corruption of memory adjacent to the pool, with a crash or further compromise of kernel state as the practical impact.\n\nThe fix validates ll_hdr_len + net_pkt_get_len(pkt) + authtag_len against IEEE802154_MTU before any copy and adds a tailroom-checking copy_pkt_to_frame() helper that returns -EMSGSIZE instead of overrunning the buffer. The same change also linearizes the whole net_buf chain into one MAC frame, so packet storage boundaries no longer become frame boundaries on the wire."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/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-09-28T20:00:01.312Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/3d4c6177d2dbd77d12d9b14cd75a00cdbd826227"
},
{
"name": "GHSA-j76j-jrjc-xgvp",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j76j-jrjc-xgvp"
}
],
"title": "Out-of-bounds write in the IEEE 802.15.4 L2 transmit path for oversized non-6LoWPAN frames",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18415",
"datePublished": "2026-09-28T20:00:01.312Z",
"dateReserved": "2026-07-30T17:54:11.604Z",
"dateUpdated": "2026-09-30T15:28:20.759Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18414 (GCVE-0-2026-18414)
Vulnerability from cvelistv5 – Published: 2026-09-28 20:00 – Updated: 2026-09-30 15:28
VLAI
EPSS
VEX
Title
Out-of-bounds write in the ADI MAX32 ADC driver due to incorrect adc_sequence buffer size validation
Summary
The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that "the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough". The ADI MAX32 driver did not honour that contract. start_read() in drivers/adc/adc_max32.c compared buffer_size, a byte count, against a sample count ((1 + extra_samplings) channels), ignoring sizeof(uint16_t), so it accepted a buffer half the required size. The samples are then stored through the uint16_t data->buffer by Wrap_MXC_ADC_GetData(), which writes two bytes per sample and advances the pointer by one uint16_t: in adc_max32_start_channel() for synchronous reads, and in adc_max32_isr() for asynchronous ones. A sequence selecting two channels with a two-byte buffer, for example, passes the check and has its second sample written past the end of the buffer.
On a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options->callback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to a MAX32 ADC device object therefore fully controls channels, buffer, buffer_size and options->extra_samplings, and can make the driver write twice as many bytes as its buffer holds. Because the check scales with extra_samplings, the overrun equals the length of the buffer itself, up to channels * 65536 bytes past its end, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.
The resulting stores are performed by the driver in kernel mode (in the system call itself, the ADC context timer, or the ADC interrupt handler for asynchronous reads), where the MPU does not restrict the thread's memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.
The fix replaces that check in start_read() with a call to the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c, passing sizeof(uint16_t) as the sample size. The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 15:19 UTC
CWE
- CWE-787 - bounds
Assigner
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-18414",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T15:19:10.980710Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T15:28:20.886Z",
"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_common.c",
"drivers/adc/adc_common.h",
"drivers/adc/adc_max32.c",
"drivers/adc/adc_mcux_lpadc.c"
],
"programRoutines": [
{
"name": "adc_max32_isr"
},
{
"name": "adc_max32_start_channel"
},
{
"name": "start_read"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.0.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that \"the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough\". The ADI MAX32 driver did not honour that contract. start_read() in drivers/adc/adc_max32.c compared buffer_size, a byte count, against a sample count ((1 + extra_samplings) channels), ignoring sizeof(uint16_t), so it accepted a buffer half the required size. The samples are then stored through the uint16_t data-\u003ebuffer by Wrap_MXC_ADC_GetData(), which writes two bytes per sample and advances the pointer by one uint16_t: in adc_max32_start_channel() for synchronous reads, and in adc_max32_isr() for asynchronous ones. A sequence selecting two channels with a two-byte buffer, for example, passes the check and has its second sample written past the end of the buffer.\n\nOn a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options-\u003ecallback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to a MAX32 ADC device object therefore fully controls channels, buffer, buffer_size and options-\u003eextra_samplings, and can make the driver write twice as many bytes as its buffer holds. Because the check scales with extra_samplings, the overrun equals the length of the buffer itself, up to channels * 65536 bytes past its end, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.\n\nThe resulting stores are performed by the driver in kernel mode (in the system call itself, the ADC context timer, or the ADC interrupt handler for asynchronous reads), where the MPU does not restrict the thread\u0027s memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.\n\nThe fix replaces that check in start_read() with a call to the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c, passing sizeof(uint16_t) as the sample size. The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started."
}
],
"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-09-28T20:00:00.133Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit 9338c518bf2b",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/9338c518bf2b6a396f166d4dbe9985ce7e44379c"
},
{
"name": "Fix commit 3bda971a52dd",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/3bda971a52ddbbec28f6fcfe3b006d34e8b9e5a9"
},
{
"name": "GHSA-ghm4-78mm-8v2c",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-ghm4-78mm-8v2c"
}
],
"title": "Out-of-bounds write in the ADI MAX32 ADC driver due to incorrect adc_sequence buffer size validation",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18414",
"datePublished": "2026-09-28T20:00:00.133Z",
"dateReserved": "2026-07-30T17:54:10.376Z",
"dateUpdated": "2026-09-30T15:28:20.886Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18413 (GCVE-0-2026-18413)
Vulnerability from cvelistv5 – Published: 2026-09-28 19:59 – Updated: 2026-09-30 20:11
VLAI
EPSS
VEX
Title
Out-of-bounds write in the NXP MCUX LPADC ADC driver due to missing adc_sequence buffer size validation
Summary
The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that "the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough". The NXP MCUX LPADC driver did not honour that contract. mcux_lpadc_start_read() in drivers/adc/adc_mcux_lpadc.c performed no buffer-size check at all before assigning data->buffer = sequence->buffer. Each completed conversion then stores one 16-bit sample per enabled channel per sampling round through an unbounded *data->buffer++: in mcux_lpadc_isr() for interrupt-driven builds, and in mcux_lpadc_dma_callback() for DMA-driven builds on releases that have the DMA path. A sequence selecting two channels with a two-byte buffer, for example, has its second sample written past the end of the buffer.
On a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options->callback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to an LPADC device object therefore fully controls channels, buffer, buffer_size and options->extra_samplings, and can request far more samples than its buffer can hold: up to channels * 65536 samples into a two-byte buffer, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.
The resulting stores are performed by the driver in kernel mode (in the ADC interrupt handler or the DMA completion callback), where the MPU does not restrict the thread's memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.
The fix calls the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c from mcux_lpadc_start_read(). The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 19:45 UTC
CWE
- CWE-787 - bounds
Assigner
References
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
2.5.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18413",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T19:45:30.410256Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T20:11:11.842Z",
"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_common.c",
"drivers/adc/adc_common.h",
"drivers/adc/adc_max32.c",
"drivers/adc/adc_mcux_lpadc.c"
],
"programRoutines": [
{
"name": "mcux_lpadc_dma_callback"
},
{
"name": "mcux_lpadc_isr"
},
{
"name": "mcux_lpadc_start_read"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "2.5.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffer_size field of struct adc_sequence in include/zephyr/drivers/adc.h documents that \"the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough\". The NXP MCUX LPADC driver did not honour that contract. mcux_lpadc_start_read() in drivers/adc/adc_mcux_lpadc.c performed no buffer-size check at all before assigning data-\u003ebuffer = sequence-\u003ebuffer. Each completed conversion then stores one 16-bit sample per enabled channel per sampling round through an unbounded *data-\u003ebuffer++: in mcux_lpadc_isr() for interrupt-driven builds, and in mcux_lpadc_dma_callback() for DMA-driven builds on releases that have the DMA path. A sequence selecting two channels with a two-byte buffer, for example, has its second sample written past the end of the buffer.\n\nOn a build with CONFIG_USERSPACE, adc_read() and adc_read_async() are system calls. The handler in drivers/adc/adc_handlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffer_size) is writable by the calling thread, and rejects a user-supplied options-\u003ecallback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to an LPADC device object therefore fully controls channels, buffer, buffer_size and options-\u003eextra_samplings, and can request far more samples than its buffer can hold: up to channels * 65536 samples into a two-byte buffer, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.\n\nThe resulting stores are performed by the driver in kernel mode (in the ADC interrupt handler or the DMA completion callback), where the MPU does not restrict the thread\u0027s memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIG_USERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.\n\nThe fix calls the new shared helper adc_sequence_validate_buffer() in drivers/adc/adc_common.c from mcux_lpadc_start_read(). The helper computes active_channels sizeof(uint16_t) (1 + extra_samplings) and returns -ENOMEM before any sampling is started."
}
],
"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-09-28T19:59:58.873Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit 9338c518bf2b",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/9338c518bf2b6a396f166d4dbe9985ce7e44379c"
},
{
"name": "Fix commit 3bda971a52dd",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/3bda971a52ddbbec28f6fcfe3b006d34e8b9e5a9"
},
{
"name": "GHSA-7jqq-2g5q-hcrp",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-7jqq-2g5q-hcrp"
}
],
"title": "Out-of-bounds write in the NXP MCUX LPADC ADC driver due to missing adc_sequence buffer size validation",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-18413",
"datePublished": "2026-09-28T19:59:58.873Z",
"dateReserved": "2026-07-30T17:54:09.140Z",
"dateUpdated": "2026-09-30T20:11:11.842Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-16513 (GCVE-0-2026-16513)
Vulnerability from cvelistv5 – Published: 2026-09-28 19:59 – Updated: 2026-09-30 20:11
VLAI
EPSS
VEX
Title
Missing write validation of user-supplied handle pointer in the RTIO syscall verifier allows arbitrary kernel write
Summary
The userspace verifier z_vrfy_rtio_sqe_copy_in_get_handles() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) validated the RTIO object handle and the sqes input array, but not the handle out-parameter. On the first loop iteration it executed *handle = sqe, storing the kernel address of the newly acquired submission-queue entry through a pointer taken verbatim from user mode, with no K_SYSCALL_MEMORY_WRITE check in front of it.
Any user-mode thread that has been granted a struct rtio kernel object can invoke the syscall with an arbitrary address in handle. That is the ordinary way an unprivileged thread uses the RTIO API, for example via sensor_read_async_mempool() or the async ADC helpers, which call rtio_sqe_copy_in_get_handles() internally. The store happens in supervisor mode before any submission-entry validation, so it fires regardless of whether the SQE contents are subsequently rejected. Only builds with CONFIG_USERSPACE and CONFIG_RTIO are affected; without CONFIG_USERSPACE the verifier is not compiled and the caller is already privileged.
The write address is fully attacker-chosen and the written value is a pointer into the caller's own RTIO ring, whose contents the caller controls (the following *sqe = sqes[i] copies an attacker-supplied struct rtio_sqe into that slot). This yields a write-what-where primitive placing a pointer to attacker-controlled data at any kernel address, sufficient to corrupt kernel function pointers, thread structures, or memory-domain partition tables, and thus to escalate from user mode to kernel mode, defeating the isolation boundary CONFIG_USERSPACE is meant to enforce. At minimum it is a reliable kernel memory-corruption and crash primitive. The reporter reproduced the write on qemu_x86: a K_USER thread changed a supervisor global from NULL to a live kernel SQE pointer.
The fix adds K_SYSCALL_MEMORY_WRITE(handle, sizeof(*handle)) (guarded by the existing optional-NULL semantics) before the loop, so the destination must lie in the calling thread's writable memory domain or the thread is terminated by K_OOPS. The neighbouring verifier z_vrfy_rtio_cqe_get_mempool_buffer(), which checked its buff/buff_len out-parameters only for read although the implementation writes through them, was hardened separately by bea93400138 ("rtio: syscalls: validate output params as writable"); that residual was materially weaker, since a read check still confines the target to the caller's own memory domain.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-30 19:45 UTC
CWE
- CWE-787 - memory-safety
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-16513",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-30T19:45:44.911882Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-30T20:11:11.980Z",
"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/rtio/rtio_syscalls.c"
],
"programRoutines": [
{
"name": "rtio_sqe_copy_in_get_handles"
},
{
"name": "z_vrfy_rtio_sqe_copy_in_get_handles"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The userspace verifier z_vrfy_rtio_sqe_copy_in_get_handles() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) validated the RTIO object handle and the sqes input array, but not the handle out-parameter. On the first loop iteration it executed *handle = sqe, storing the kernel address of the newly acquired submission-queue entry through a pointer taken verbatim from user mode, with no K_SYSCALL_MEMORY_WRITE check in front of it.\n\nAny user-mode thread that has been granted a struct rtio kernel object can invoke the syscall with an arbitrary address in handle. That is the ordinary way an unprivileged thread uses the RTIO API, for example via sensor_read_async_mempool() or the async ADC helpers, which call rtio_sqe_copy_in_get_handles() internally. The store happens in supervisor mode before any submission-entry validation, so it fires regardless of whether the SQE contents are subsequently rejected. Only builds with CONFIG_USERSPACE and CONFIG_RTIO are affected; without CONFIG_USERSPACE the verifier is not compiled and the caller is already privileged.\n\nThe write address is fully attacker-chosen and the written value is a pointer into the caller\u0027s own RTIO ring, whose contents the caller controls (the following *sqe = sqes[i] copies an attacker-supplied struct rtio_sqe into that slot). This yields a write-what-where primitive placing a pointer to attacker-controlled data at any kernel address, sufficient to corrupt kernel function pointers, thread structures, or memory-domain partition tables, and thus to escalate from user mode to kernel mode, defeating the isolation boundary CONFIG_USERSPACE is meant to enforce. At minimum it is a reliable kernel memory-corruption and crash primitive. The reporter reproduced the write on qemu_x86: a K_USER thread changed a supervisor global from NULL to a live kernel SQE pointer.\n\nThe fix adds K_SYSCALL_MEMORY_WRITE(handle, sizeof(*handle)) (guarded by the existing optional-NULL semantics) before the loop, so the destination must lie in the calling thread\u0027s writable memory domain or the thread is terminated by K_OOPS. The neighbouring verifier z_vrfy_rtio_cqe_get_mempool_buffer(), which checked its buff/buff_len out-parameters only for read although the implementation writes through them, was hardened separately by bea93400138 (\"rtio: syscalls: validate output params as writable\"); that residual was materially weaker, since a read check still confines the target to the caller\u0027s own memory domain."
}
],
"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-09-28T19:59:57.736Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/95c355c425763fbe5e735b9ef54dacce2c4ce21f"
},
{
"name": "GHSA-fwmc-q8qg-jcxq",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-fwmc-q8qg-jcxq"
}
],
"title": "Missing write validation of user-supplied handle pointer in the RTIO syscall verifier allows arbitrary kernel write",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-16513",
"datePublished": "2026-09-28T19:59:57.736Z",
"dateReserved": "2026-07-21T21:42:58.503Z",
"dateUpdated": "2026-09-30T20:11:11.980Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17054 (GCVE-0-2026-17054)
Vulnerability from cvelistv5 – Published: 2026-09-21 21:16 – Updated: 2026-09-22 15:51
VLAI
EPSS
VEX
Title
Out-of-bounds read and permanent loss of Wi-Fi reception in the ESP-hosted SPI driver's frame reassembly
Summary
The Espressif ESP-hosted Wi-Fi driver (drivers/wifi/esp_hosted/) parses frames received over SPI from the ESP co-processor in esp_hosted_event_task(). For control frames it took the 16-bit TLV field data_length straight off the wire and passed it to pb_istream_from_buffer(frame.data_value, frame.data_length) without checking it against the frame length or the receive buffer. frame.data_value sits 26 bytes into a 3188-byte stack object, so a data_length of up to 0xFFFF makes pb_decode() read up to roughly 62 KB past the end of that object.
Only the first fragment of a fragmented control response carries a TLV header; the pre-fix driver performed half-duplex SPI transactions and silently discarded any frame the co-processor queued while the host was transmitting (esp_hosted_hal_spi_transfer() aliased the RX buffer onto the TX buffer). When the discarded frame is the first fragment of a fragmented response, the driver treats the next fragment as a new frame — its per-fragment header and checksum are genuine, so both validation steps pass — and reads the TLV header out of raw protobuf continuation bytes. Those bytes come from control responses whose size and content an adjacent, unauthenticated attacker can influence, notably the AP scan list, which grows with the number and SSID length of access points in radio range.
The impact is denial of service rather than disclosure. Reading past the end of the RAM region faults the device, and CONFIG_NANOPB_ENABLE_MALLOC is selected by the driver, so garbage length prefixes read out of bounds also drive heap allocations. The out-of-bounds bytes themselves do not reach the application: pb_decode() is started mid-stream on raw protobuf continuation bytes and so almost always fails outright, and anything that did decode would still have to pass esp_hosted_response(), which requires an exact msg_id match against the pending request, and then esp_hosted_ctrl_response(), which requires a success resp — an attacker influences the size and content of legitimate control responses, not the structure decoded out of misaligned bytes. Two related defects in the same receive path make the denial of service permanent: the fragment reassembly guard was sized with ESP_FRAME_SIZE instead of ESP_FRAME_MAX_PAYLOAD and, when tripped, returned from the sole RX thread instead of dropping the frame, and unhandled control events were queued with k_msgq_put(..., K_FOREVER) on an eight-entry queue that nothing drains, blocking that same thread. The driver has no watchdog or restart path, so either condition ends all Wi-Fi reception until the device is rebooted.
Severity
5.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 15:51 UTC
CWE
- CWE-125 - bounds
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-17054",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T15:51:43.430440Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T15:51:55.360Z",
"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/wifi/esp_hosted/Kconfig.esp_hosted",
"drivers/wifi/esp_hosted/esp_hosted_hal.c",
"drivers/wifi/esp_hosted/esp_hosted_util.h",
"drivers/wifi/esp_hosted/esp_hosted_wifi.c",
"drivers/wifi/esp_hosted/esp_hosted_wifi.h"
],
"programRoutines": [
{
"name": "esp_hosted_event_task"
},
{
"name": "esp_hosted_hal_spi_transfer"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.2.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Espressif ESP-hosted Wi-Fi driver (drivers/wifi/esp_hosted/) parses frames received over SPI from the ESP co-processor in esp_hosted_event_task(). For control frames it took the 16-bit TLV field data_length straight off the wire and passed it to pb_istream_from_buffer(frame.data_value, frame.data_length) without checking it against the frame length or the receive buffer. frame.data_value sits 26 bytes into a 3188-byte stack object, so a data_length of up to 0xFFFF makes pb_decode() read up to roughly 62 KB past the end of that object.\n\nOnly the first fragment of a fragmented control response carries a TLV header; the pre-fix driver performed half-duplex SPI transactions and silently discarded any frame the co-processor queued while the host was transmitting (esp_hosted_hal_spi_transfer() aliased the RX buffer onto the TX buffer). When the discarded frame is the first fragment of a fragmented response, the driver treats the next fragment as a new frame \u2014 its per-fragment header and checksum are genuine, so both validation steps pass \u2014 and reads the TLV header out of raw protobuf continuation bytes. Those bytes come from control responses whose size and content an adjacent, unauthenticated attacker can influence, notably the AP scan list, which grows with the number and SSID length of access points in radio range.\n\nThe impact is denial of service rather than disclosure. Reading past the end of the RAM region faults the device, and CONFIG_NANOPB_ENABLE_MALLOC is selected by the driver, so garbage length prefixes read out of bounds also drive heap allocations. The out-of-bounds bytes themselves do not reach the application: pb_decode() is started mid-stream on raw protobuf continuation bytes and so almost always fails outright, and anything that did decode would still have to pass esp_hosted_response(), which requires an exact msg_id match against the pending request, and then esp_hosted_ctrl_response(), which requires a success resp \u2014 an attacker influences the size and content of legitimate control responses, not the structure decoded out of misaligned bytes. Two related defects in the same receive path make the denial of service permanent: the fragment reassembly guard was sized with ESP_FRAME_SIZE instead of ESP_FRAME_MAX_PAYLOAD and, when tripped, returned from the sole RX thread instead of dropping the frame, and unhandled control events were queued with k_msgq_put(..., K_FOREVER) on an eight-entry queue that nothing drains, blocking that same thread. The driver has no watchdog or restart path, so either condition ends all Wi-Fi reception until the device is rebooted."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "bounds",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T21:16:05.314Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/93c32f240c9661f321233c134cfdd07f8dc97bb8"
},
{
"name": "GHSA-mq9g-c5j9-79v5",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-mq9g-c5j9-79v5"
}
],
"title": "Out-of-bounds read and permanent loss of Wi-Fi reception in the ESP-hosted SPI driver\u0027s frame reassembly",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17054",
"datePublished": "2026-09-21T21:16:05.314Z",
"dateReserved": "2026-07-24T13:31:08.179Z",
"dateUpdated": "2026-09-22T15:51:55.360Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-15890 (GCVE-0-2026-15890)
Vulnerability from cvelistv5 – Published: 2026-09-21 21:16 – Updated: 2026-09-22 15:50
VLAI
EPSS
VEX
Title
AEAD nonce reuse in Zephyr secure_storage ITS default nonce provider due to missing thread synchronization
Summary
The default AEAD nonce provider for the PSA Internal Trusted Storage transform module, secure_storage_its_transform_aead_get_nonce() in subsys/secure_storage/src/its/transform/aead_get.c, stores its nonce counter in unsynchronized function-local static variables (s_nonce and s_nonce_initialized). Every ITS write obtains its AES-GCM or ChaCha20-Poly1305 nonce here via secure_storage_its_transform_to_store().
Because the function held no lock, two threads calling it concurrently race on the shared statics: the initialization path (psa_generate_random() followed by memcpy()) and the non-atomic increment-then-copy path can each hand the same nonce value to two distinct encryption operations, and can lose increments so the counter repeats values it was designed never to repeat. The ITS layer (secure_storage_its_set() in subsys/secure_storage/src/its/implementation.c) performs no serialization of its own, so concurrent same-UID writes reach the racy provider directly.
Reusing a nonce with the same key under AES-GCM or ChaCha20-Poly1305 is a catastrophic AEAD failure: it leaks the XOR of the two plaintexts (ITS routinely stores secrets, including PSA persistent keys) and, for GCM, exposes the authentication key, enabling forgery of stored entries. Because the AEAD key is derived per entry UID, the security-relevant collision is two concurrent writes to the same UID both receiving the same nonce; an adversary able to read the raw backing storage can then exploit the reuse.
Both ITS store back-ends shipped with Zephyr, zms.c and the settings/NVS back-end in settings.c, are log-structured flash stores with deferred garbage collection, so an entry superseded by a rewrite remains physically present in the partition until its sector is reclaimed. Two same-UID writes that race therefore leave both ciphertexts readable in the raw image at once, which is the condition the nonce reuse needs to be exploitable. The trigger remains narrow: both built-in key providers (DEVICE_ID_HASH and ENTRY_UID_HASH) salt the derived key with the entry UID, so reuse across different UIDs is harmless, and the exposure requires an application that writes the same UID concurrently from two threads.
The fix serializes the provider with a K_MUTEX_DEFINE(s_nonce_mutex) held for the duration of nonce generation.
Severity
5.3 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-22 15:50 UTC
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.0.0 , < 4.3.2
(semver)
Affected: 4.4.0 , < 4.4.2 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-15890",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T15:50:50.587244Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T15:50:59.284Z",
"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/secure_storage/src/its/transform/aead_get.c"
],
"programRoutines": [
{
"name": "secure_storage_its_transform_aead_get_nonce"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.3.2",
"status": "affected",
"version": "4.0.0",
"versionType": "semver"
},
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.4.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The default AEAD nonce provider for the PSA Internal Trusted Storage transform module, secure_storage_its_transform_aead_get_nonce() in subsys/secure_storage/src/its/transform/aead_get.c, stores its nonce counter in unsynchronized function-local static variables (s_nonce and s_nonce_initialized). Every ITS write obtains its AES-GCM or ChaCha20-Poly1305 nonce here via secure_storage_its_transform_to_store().\n\nBecause the function held no lock, two threads calling it concurrently race on the shared statics: the initialization path (psa_generate_random() followed by memcpy()) and the non-atomic increment-then-copy path can each hand the same nonce value to two distinct encryption operations, and can lose increments so the counter repeats values it was designed never to repeat. The ITS layer (secure_storage_its_set() in subsys/secure_storage/src/its/implementation.c) performs no serialization of its own, so concurrent same-UID writes reach the racy provider directly.\n\nReusing a nonce with the same key under AES-GCM or ChaCha20-Poly1305 is a catastrophic AEAD failure: it leaks the XOR of the two plaintexts (ITS routinely stores secrets, including PSA persistent keys) and, for GCM, exposes the authentication key, enabling forgery of stored entries. Because the AEAD key is derived per entry UID, the security-relevant collision is two concurrent writes to the same UID both receiving the same nonce; an adversary able to read the raw backing storage can then exploit the reuse.\n\nBoth ITS store back-ends shipped with Zephyr, zms.c and the settings/NVS back-end in settings.c, are log-structured flash stores with deferred garbage collection, so an entry superseded by a rewrite remains physically present in the partition until its sector is reclaimed. Two same-UID writes that race therefore leave both ciphertexts readable in the raw image at once, which is the condition the nonce reuse needs to be exploitable. The trigger remains narrow: both built-in key providers (DEVICE_ID_HASH and ENTRY_UID_HASH) salt the derived key with the entry UID, so reuse across different UIDs is harmless, and the exposure requires an application that writes the same UID concurrently from two threads.\n\nThe fix serializes the provider with a K_MUTEX_DEFINE(s_nonce_mutex) held for the duration of nonce generation."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-323",
"description": "crypto",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-362",
"description": "crypto",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T21:16:04.169Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/dc66397309248271df1fd0131d68ce8ea62bf91b"
},
{
"name": "GHSA-23jw-7xv2-xr28",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-23jw-7xv2-xr28"
}
],
"title": "AEAD nonce reuse in Zephyr secure_storage ITS default nonce provider due to missing thread synchronization",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-15890",
"datePublished": "2026-09-21T21:16:04.169Z",
"dateReserved": "2026-07-15T17:38:06.560Z",
"dateUpdated": "2026-09-22T15:50:59.284Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17052 (GCVE-0-2026-17052)
Vulnerability from cvelistv5 – Published: 2026-09-21 18:35 – Updated: 2026-09-21 18:43
VLAI
EPSS
VEX
Title
Missing user-pointer validation in tgpio_pin_read_ts_ec syscall handler allows arbitrary supervisor-memory write from userspace
Summary
The Time-aware GPIO syscall verification handler z_vrfy_tgpio_pin_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_handlers.c validated only the port device object and passed the caller-supplied timestamp and event_count output pointers to the driver without a K_SYSCALL_MEMORY_WRITE() check. The other handlers in the same file (z_vrfy_tgpio_port_get_time(), z_vrfy_tgpio_port_get_cycles_per_second()) already performed that check, so the omission left one syscall unguarded.
tgpio_pin_read_ts_ec() is declared __syscall, so with CONFIG_USERSPACE=y an unprivileged user-mode thread that has been granted access to the TGPIO device object can invoke it with arbitrary pointer values. tgpio_intel_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_intel.c bounds-checks only the pin index and then unconditionally performs timestamp = ... and event_count = ..., executing two 8-byte stores in supervisor mode at addresses chosen by the user-mode caller.
The result is a write-what-where primitive that crosses the userspace/kernel boundary: the target address is fully attacker-chosen and the stored values are the hardware time-capture and event-counter register contents. Corrupting kernel data structures this way can escalate the calling thread to supervisor privilege or crash the system; the device-object permission required is a narrow capability that is not intended to confer any kernel-memory access. The fix adds the two missing K_SYSCALL_MEMORY_WRITE() validations before the driver call.
Exposure is narrow in practice. Only builds with CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y compile the affected file, and from v3.6.0 onward the file additionally referenced a relocated header (<zephyr/syscall_handler.h>) and removed Z_SYSCALL_* macros, so such a configuration failed to build until those were repaired after v4.4.0. Downstream trees that locally corrected that breakage, and v3.5.0 builds where it did not exist, are the exposed population.
Severity
7.8 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-21 18:42 UTC
CWE
- CWE-787 - memory-safety
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-17052",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-21T18:42:55.294194Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T18:43:05.834Z",
"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/timeaware_gpio/timeaware_gpio_handlers.c"
],
"programRoutines": [
{
"name": "tgpio_intel_read_ts_ec"
},
{
"name": "tgpio_pin_read_ts_ec"
},
{
"name": "z_vrfy_tgpio_pin_read_ts_ec"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.5.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Time-aware GPIO syscall verification handler z_vrfy_tgpio_pin_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_handlers.c validated only the port device object and passed the caller-supplied timestamp and event_count output pointers to the driver without a K_SYSCALL_MEMORY_WRITE() check. The other handlers in the same file (z_vrfy_tgpio_port_get_time(), z_vrfy_tgpio_port_get_cycles_per_second()) already performed that check, so the omission left one syscall unguarded.\n\ntgpio_pin_read_ts_ec() is declared __syscall, so with CONFIG_USERSPACE=y an unprivileged user-mode thread that has been granted access to the TGPIO device object can invoke it with arbitrary pointer values. tgpio_intel_read_ts_ec() in drivers/timeaware_gpio/timeaware_gpio_intel.c bounds-checks only the pin index and then unconditionally performs timestamp = ... and event_count = ..., executing two 8-byte stores in supervisor mode at addresses chosen by the user-mode caller.\n\nThe result is a write-what-where primitive that crosses the userspace/kernel boundary: the target address is fully attacker-chosen and the stored values are the hardware time-capture and event-counter register contents. Corrupting kernel data structures this way can escalate the calling thread to supervisor privilege or crash the system; the device-object permission required is a narrow capability that is not intended to confer any kernel-memory access. The fix adds the two missing K_SYSCALL_MEMORY_WRITE() validations before the driver call.\n\nExposure is narrow in practice. Only builds with CONFIG_USERSPACE=y and CONFIG_TIMEAWARE_GPIO=y compile the affected file, and from v3.6.0 onward the file additionally referenced a relocated header (\u003czephyr/syscall_handler.h\u003e) and removed Z_SYSCALL_* macros, so such a configuration failed to build until those were repaired after v4.4.0. Downstream trees that locally corrected that breakage, and v3.5.0 builds where it did not exist, are the exposed population."
}
],
"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-09-21T18:35:30.081Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/26264fffc17c2174319394ffa274af3f6efdc221"
},
{
"name": "GHSA-8qw6-x76h-8mpc",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8qw6-x76h-8mpc"
}
],
"title": "Missing user-pointer validation in tgpio_pin_read_ts_ec syscall handler allows arbitrary supervisor-memory write from userspace",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17052",
"datePublished": "2026-09-21T18:35:30.081Z",
"dateReserved": "2026-07-24T13:31:05.682Z",
"dateUpdated": "2026-09-21T18:43:05.834Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17051 (GCVE-0-2026-17051)
Vulnerability from cvelistv5 – Published: 2026-09-21 16:41 – Updated: 2026-09-21 18:48
VLAI
EPSS
VEX
Title
Out-of-bounds write in the Intel SEDI IPM driver from an unvalidated inbound doorbell length
Summary
The Intel SEDI IPM (inter-processor mailbox) driver in drivers/ipm/ipm_sedi.c handles an inbound message interrupt in ipm_event_dispose(). It read the peer-written doorbell register, extracted the payload length with IPC_HEADER_GET_LENGTH(), and passed that length straight to sedi_ipc_read_msg() to copy the message into struct ipm_sedi_context.incoming_data_buf, without checking it against the buffer size. The doorbell length field is 10 bits wide (IPC_HEADER_LENGTH_MASK is 0x03FF), so it can encode up to 1023 bytes, while incoming_data_buf is IPC_DATA_LEN_MAX (128) bytes. The bounds check in the underlying HAL sedi_ipc_read_msg() is a DBG_CHECK that compiles away unless CONFIG_DEBUG is set, so no check remained in a production image.
The doorbell register is written by the peer processor on the other side of the IPC link — for the intel_ish_5_* targets, the host CPU's ISH driver, reached through the device's memory-mapped register window. Host-side software with driver-level or raw BAR access can therefore set a length of up to 1023 and cause the interrupt handler to copy far past the destination buffer. The affected path requires an application to have registered an IPM receive callback via ipm_register_callback(), which is the driver's normal mode of use.
The result is an out-of-bounds write of up to 895 bytes into static (.bss) memory, performed in interrupt context. The overflow first clobbers the rest of struct ipm_sedi_context — including the k_sem and k_mutex used by the transmit path, whose wait queues contain self-referential list pointers — and then adjacent static data, giving a kernel data-structure corruption and crash primitive. The overflowing bytes are read from registers following the message window, a portion of which are themselves peer-programmable. The fix rejects any doorbell whose encoded length exceeds IPC_DATA_LEN_MAX, logging it and acknowledging the doorbell so the peer is not left waiting.
Severity
6 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-21 18:48 UTC
CWE
- CWE-787 - bounds
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-17051",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-21T18:48:41.746593Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T18:48:52.333Z",
"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/ipm/ipm_sedi.c"
],
"programRoutines": [
{
"name": "ipm_event_dispose"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "3.5.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The Intel SEDI IPM (inter-processor mailbox) driver in drivers/ipm/ipm_sedi.c handles an inbound message interrupt in ipm_event_dispose(). It read the peer-written doorbell register, extracted the payload length with IPC_HEADER_GET_LENGTH(), and passed that length straight to sedi_ipc_read_msg() to copy the message into struct ipm_sedi_context.incoming_data_buf, without checking it against the buffer size. The doorbell length field is 10 bits wide (IPC_HEADER_LENGTH_MASK is 0x03FF), so it can encode up to 1023 bytes, while incoming_data_buf is IPC_DATA_LEN_MAX (128) bytes. The bounds check in the underlying HAL sedi_ipc_read_msg() is a DBG_CHECK that compiles away unless CONFIG_DEBUG is set, so no check remained in a production image.\n\nThe doorbell register is written by the peer processor on the other side of the IPC link \u2014 for the intel_ish_5_* targets, the host CPU\u0027s ISH driver, reached through the device\u0027s memory-mapped register window. Host-side software with driver-level or raw BAR access can therefore set a length of up to 1023 and cause the interrupt handler to copy far past the destination buffer. The affected path requires an application to have registered an IPM receive callback via ipm_register_callback(), which is the driver\u0027s normal mode of use.\n\nThe result is an out-of-bounds write of up to 895 bytes into static (.bss) memory, performed in interrupt context. The overflow first clobbers the rest of struct ipm_sedi_context \u2014 including the k_sem and k_mutex used by the transmit path, whose wait queues contain self-referential list pointers \u2014 and then adjacent static data, giving a kernel data-structure corruption and crash primitive. The overflowing bytes are read from registers following the message window, a portion of which are themselves peer-programmable. The fix rejects any doorbell whose encoded length exceeds IPC_DATA_LEN_MAX, logging it and acknowledging the doorbell so the peer is not left waiting."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 6,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:H/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-09-21T16:41:24.528Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/74c7d27925055e8c3c8aef7a9f16cae6a8c64b70"
},
{
"name": "GHSA-78p3-4gv3-qjh9",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-78p3-4gv3-qjh9"
}
],
"title": "Out-of-bounds write in the Intel SEDI IPM driver from an unvalidated inbound doorbell length",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17051",
"datePublished": "2026-09-21T16:41:24.528Z",
"dateReserved": "2026-07-24T13:31:04.469Z",
"dateUpdated": "2026-09-21T18:48:52.333Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17050 (GCVE-0-2026-17050)
Vulnerability from cvelistv5 – Published: 2026-09-21 16:41 – Updated: 2026-09-21 18:49
VLAI
EPSS
VEX
Title
Double free of the USB host configuration descriptor when device enumeration fails
Summary
The experimental USB host stack allocates a per-device configuration-descriptor buffer, udev->cfg_desc, from the dedicated usb_device_heap in usbh_device_set_configuration() (subsys/usb/host/usbh_device.c). On three failure paths — a failed full-length GET_DESCRIPTOR(CONFIGURATION) read, a mismatch between the short and full descriptor reads, and a rejected descriptor in parse_configuration_descriptor() — the buffer was released with k_heap_free() but the pointer was left dangling. The cleanup in usbh_device_free() is guarded only by if (udev->cfg_desc != NULL), so it frees the same block a second time.
The path is driven entirely by the attached peripheral: usbh_device_connect() calls usbh_device_init(), which ends in usbh_device_set_configuration(), and on failure usbh_device_connect() calls usbh_device_free(). On v4.4.x this happens during the same enumeration, with no unplug required; on v4.1.0–v4.3.x the second free instead arrives via dev_removed_handler()/dev_connected_handler() in subsys/usb/host/usbh_core.c, so it requires a removal or duplicate-connect event after the failed enumeration — a sequence the attached device fully controls. A malicious or malformed USB device only has to answer the first 9-byte configuration-descriptor request with a well-formed header and then fail any of the three checks, for example by returning a full descriptor whose interface count disagrees with bNumInterfaces, or by answering the second read with different bytes.
The result is a double free on usb_device_heap. On builds where lib/heap hardening is active (the current default CONFIG_SYS_HEAP_HARDENING_BASIC), sys_heap_free() detects the already-free chunk and calls k_panic(), giving a deterministic, peripheral-triggered denial of service of the USB host. On builds without that detection — earlier releases, or CONFIG_SYS_HEAP_HARDENING_NONE — the second free manipulates a chunk already on the free list, corrupting the heap's free list so that later allocations can return overlapping or invalid blocks.
Exploitation beyond denial of service is bounded by the fact that usb_device_heap is a small dedicated heap (CONFIG_USBH_USB_DEVICE_HEAP, default 1024 bytes) whose only client is this descriptor buffer, and by CONFIG_USB_HOST_STACK being marked experimental and disabled by default. The fix sets udev->cfg_desc = NULL after every k_heap_free(), making the cleanup guard sound.
Severity
5.7 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-21 18:49 UTC
CWE
- CWE-415 - use-after-free
Assigner
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| zephyrproject | zephyr |
Affected:
4.1.0 , < 4.4.2
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-17050",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-21T18:49:15.331848Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T18:49:25.187Z",
"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/usb/host/usbh_device.c"
],
"programRoutines": [
{
"name": "usbh_device_free"
},
{
"name": "usbh_device_set_configuration"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "The experimental USB host stack allocates a per-device configuration-descriptor buffer, udev-\u003ecfg_desc, from the dedicated usb_device_heap in usbh_device_set_configuration() (subsys/usb/host/usbh_device.c). On three failure paths \u2014 a failed full-length GET_DESCRIPTOR(CONFIGURATION) read, a mismatch between the short and full descriptor reads, and a rejected descriptor in parse_configuration_descriptor() \u2014 the buffer was released with k_heap_free() but the pointer was left dangling. The cleanup in usbh_device_free() is guarded only by if (udev-\u003ecfg_desc != NULL), so it frees the same block a second time.\n\nThe path is driven entirely by the attached peripheral: usbh_device_connect() calls usbh_device_init(), which ends in usbh_device_set_configuration(), and on failure usbh_device_connect() calls usbh_device_free(). On v4.4.x this happens during the same enumeration, with no unplug required; on v4.1.0\u2013v4.3.x the second free instead arrives via dev_removed_handler()/dev_connected_handler() in subsys/usb/host/usbh_core.c, so it requires a removal or duplicate-connect event after the failed enumeration \u2014 a sequence the attached device fully controls. A malicious or malformed USB device only has to answer the first 9-byte configuration-descriptor request with a well-formed header and then fail any of the three checks, for example by returning a full descriptor whose interface count disagrees with bNumInterfaces, or by answering the second read with different bytes.\n\nThe result is a double free on usb_device_heap. On builds where lib/heap hardening is active (the current default CONFIG_SYS_HEAP_HARDENING_BASIC), sys_heap_free() detects the already-free chunk and calls k_panic(), giving a deterministic, peripheral-triggered denial of service of the USB host. On builds without that detection \u2014 earlier releases, or CONFIG_SYS_HEAP_HARDENING_NONE \u2014 the second free manipulates a chunk already on the free list, corrupting the heap\u0027s free list so that later allocations can return overlapping or invalid blocks.\n\nExploitation beyond denial of service is bounded by the fact that usb_device_heap is a small dedicated heap (CONFIG_USBH_USB_DEVICE_HEAP, default 1024 bytes) whose only client is this descriptor buffer, and by CONFIG_USB_HOST_STACK being marked experimental and disabled by default. The fix sets udev-\u003ecfg_desc = NULL after every k_heap_free(), making the cleanup guard sound."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 5.7,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-415",
"description": "use-after-free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-21T16:41:23.472Z",
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr"
},
"references": [
{
"name": "Fix commit",
"tags": [
"patch"
],
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/d46a8c1f8fb65e1f80b44bd651a6dafea747602e"
},
{
"name": "GHSA-r7xw-9jhg-88cm",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-r7xw-9jhg-88cm"
}
],
"title": "Double free of the USB host configuration descriptor when device enumeration fails",
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"assignerShortName": "zephyr",
"cveId": "CVE-2026-17050",
"datePublished": "2026-09-21T16:41:23.472Z",
"dateReserved": "2026-07-24T13:31:03.256Z",
"dateUpdated": "2026-09-21T18:49:25.187Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}