Rtos
Monthly
An insufficient buffer-size validation defect in Zephyr RTOS's ADI MAX32 ADC driver (drivers/adc/adc_max32.c) allows a local, low-privileged user-mode thread to write up to twice the length of its supplied buffer into kernel memory, producing attacker-controlled out-of-bounds writes at an attacker-chosen offset. Exploitation requires a build compiled with CONFIG_USERSPACE running on ADI MAX32 hardware where the calling thread has already been granted access to a MAX32 ADC device object; on such a build the attacker fully controls channels, buffer, buffer_size and options->extra_samplings, and the resulting corruption of adjacent memory, kernel data or thread stacks is a plausible local privilege-escalation and denial-of-service primitive (CVSS 7.8, AV:L/PR:L). The flaw is not remotely exploitable, and builds without CONFIG_USERSPACE are reduced to a caller-side robustness defect since the application supplies its own buffer; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
An out-of-bounds kernel-mode write in Zephyr RTOS's NXP MCUX LPADC driver (drivers/adc/adc_mcux_lpadc.c) lets an unprivileged user-mode thread corrupt memory outside its own partition, providing a genuine local privilege-escalation and denial-of-service primitive rather than an inflated high-severity score. The bug affects builds compiled with CONFIG_USERSPACE that use the MCUX LPADC driver in interrupt-driven mode (or DMA-driven mode on releases carrying the DMA path), where adc_read()/adc_read_async() are system calls: a thread already granted access to the LPADC device object controls channels, buffer, buffer_size and options->extra_samplings, and can demand up to channels × 65536 samples into a tiny buffer, causing the driver's ISR or DMA callback to walk past the buffer while running in kernel mode where the MPU does not confine it. No public exploit code or confirmed active exploitation has been identified at time of analysis, but the CVSS vector (7.8, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects high confidentiality and integrity impact from an authenticated local attacker, and upstream fixes are available.
Kernel memory corruption in Zephyr RTOS arises from the RTIO userspace syscall verifier z_vrfy_rtio_sqe_copy_in_get_handles(), which validates the RTIO object handle and the incoming sqes array but never checks that the caller-supplied handle out-parameter is writable before executing *handle = sqe in supervisor mode. Any user-mode thread that has been granted a struct rtio kernel object - the normal situation for applications using sensor_read_async_mempool() or the async ADC helpers, which call rtio_sqe_copy_in_get_handles() internally - can supply an arbitrary destination address and thereby obtain a write-what-where primitive that stores a pointer to attacker-controlled ring data at any kernel location, corrupting function pointers, thread structures or memory-domain partition tables and breaking the CONFIG_USERSPACE isolation boundary. The issue is local-only and build-gated (CVSS 7.8, AV:L/PR:L, CWE-787), requires both CONFIG_USERSPACE and CONFIG_RTIO, and no public exploit code has been identified at time of analysis, although an upstream vendor fix and GitHub security advisory are available.
Memory corruption in Wind River VxWorks 7 occurs when a task passes crafted arguments to a specific system call, causing an out-of-bounds write inside the RTOS memory-management subsystem and giving the caller full confidentiality, integrity, and availability impact on the running instance (CVSS 3.1 7.8 HIGH). The flaw is local in nature - per the vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) the attacker must already execute code on the device as at least a low-privileged task, so only VxWorks 7 deployments that run untrusted or lower-trust code are realistically exposed; locked-down devices that execute only vendor-signed firmware are not remotely reachable through this bug. All VxWorks 7 builds prior to version 26.09 are affected, and there is no public exploit code or CISA KEV entry identified at time of analysis.
An out-of-bounds read in Zephyr's MCUmgr SMP-over-console transport (subsys/mgmt/mcumgr/transport/src/serial_util.c) lets a single 7-byte, unauthenticated console line underflow a net_buf length field and hand the SMP layer a bogus ~65 KB payload window over a buffer whose data area defaults to 384 bytes. The flaw affects builds that enable 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; the test-only CONFIG_MCUMGR_TRANSPORT_DUMMY loopback carries the same pattern but has no external input path and is not exploitable. Because exploitation needs only write access to the management console - on many boards an exposed USB CDC-ACM port rather than a bare UART header - the practical impact is a faulted MCUmgr thread (denial of service) plus possible limited memory disclosure via the default-enabled os echo handler; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Denial of service in the Zephyr RTOS LwM2M client: the CoAP Block1 write handler can be driven into a NULL pointer dereference that crashes or resets the device. Affected are Zephyr builds using the LwM2M engine with block-wise transfer handling, particularly NoSec deployments where CONFIG_LWM2M_DTLS_SUPPORT is disabled (it has no default, so this is a common configuration); an unauthenticated remote peer that can reach the LwM2M UDP socket - an on-path or address-spoofing attacker, or a bootstrap/lower-trust server - first exhausts the static Block1 context pool (CONFIG_LWM2M_NUM_BLOCK1_CONTEXT, default 3) with three incomplete block-wise writes, then sends a fourth first-block write to hit the unguarded store. The assessed impact is availability only (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 5.9), and no public exploit code was identified at time of analysis; the multi-request pool-exhaustion sequence is the main factor keeping complexity high.
Repeated network-interface link-down events can crash or reset devices running Zephyr RTOS v4.3.0 that keep a listening TCP socket open, because the BSD-socket layer parks a pending errno value in the net_context user_data field while the TCP core simultaneously expects that field to hold a parent context pointer; a second interface-down event forwards the stale integer to zsock_accepted_cb(), which dereferences it as a pointer and writes through it, producing a wild-pointer access and a kernel fatal error (denial of service, not attacker-directed memory corruption). The flaw is reachable by unauthenticated adjacent attackers who can force the link down repeatedly (CVSS 3.1 AV:A/AC:L/PR:N/UI:N, 6.5, availability-only impact), and no public exploit code or confirmed active exploitation has been identified at time of analysis. Zephyr v4.3.1 and v4.4.x carry a follow-up change that clears the accept callback after the error path, reducing the issue to a narrow handshake-versus-interface-down race plus an unconditional getsockopt(SO_ERROR) read-back of the kernel pointer stored in user_data, so those lines are far less practically exploitable than v4.3.0.
Local denial of service in Wind River VxWorks 7 (all releases prior to 26.09) lets a low-privileged local task exhaust kernel memory by invoking process-management system calls whose specific arguments cause the subsystem to skip freeing allocated kernel memory when the calling application terminates. Repeated invocation accumulates the leak until the kernel memory pool is depleted, producing a high availability impact (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited; Wind River has fixed it in VxWorks 7 version 26.09.
Memory pool exhaustion in Wind River VxWorks 7 releases 24.03 through 26.03 can terminate system operations when specific service routines are invoked while the device is in a non-default configuration state, because allocated memory pools are not released before the failure propagates. The weakness is local and availability-focused (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H per independent assessment): an attacker needs low-privileged local execution on the RTOS and the affected services must be reachable, and no user interaction or network path is required. Default installations are not affected, the configuration prerequisite plus the local-access requirement substantially narrow the realistic attacker population, and no public exploit identified at time of analysis; Wind River has fixed the issue in VxWorks 7 26.09. Overall this is a moderate-severity, low-real-world-priority issue rather than a broadly exploitable one.
An out-of-bounds read in the Zephyr RTOS CoAP link-format helper match_path_uri() (subsys/net/lib/coap/coap_link_format.c) allows an unauthenticated remote attacker to drive the URI comparison loop one or more bytes past the end of a Uri-Query href= option value by sending a GET /.well-known/core?href=/<prefix> request whose value is a strict prefix of a longer registered resource path. Only devices running the Zephyr CoAP server subsystem with CONFIG_COAP_SERVER_WELL_KNOWN_CORE enabled (the default) and at least one resource declaring struct coap_core_metadata attributes reach the vulnerable code path. The over-read is bounded - in practice a single byte, limited by the compared path length - reads only uninitialized stack tail rather than receive-buffer or attacker-controlled data, cannot influence the response, and yields undefined behaviour rather than information disclosure or a matching error; no public exploit code was identified at time of analysis, and the assessed severity is Low (CVSS 3.7).
A supervisor-mode out-of-bounds write exists in the Zephyr RTOS 802.15.4 L2 transmit path: ieee802154_send() copies packet data into a fixed 125-byte frame buffer without validating the packet length on the unfragmented code path. On builds with CONFIG_NET_L2_IEEE802154_FRAGMENT (enabled by default with CONFIG_NET_6LO), local code that opens a NET_AF_PACKET socket (NET_SOCK_RAW, which skips the 6LoWPAN encoder, or NET_SOCK_DGRAM, which returns early on the address-family check) bound to an 802.15.4 interface can send a payload larger than IEEE802154_MTU and corrupt memory adjacent to the transmit buffer pool, causing a crash or further compromise of kernel state. The flaw is not reachable from the radio because ieee802154_6lo_encode_pkt() length-checks IPv6 packets and forces fragmentation; in a CONFIG_USERSPACE build an unprivileged thread can reach it through the zsock_socket()/zsock_sendto() syscalls, though the overrun is bounded to roughly ll_hdr_len + 3 bytes with the default fixed-size net_buf configuration. No public exploit code was identified at time of analysis and the vendor patch is available (commit 3d4c6177d2dbd77d12d9b14cd75a00cdbd826227).
Local resource exhaustion in Wind River VxWorks 7 (versions prior to 26.09) allows a low-privileged local application to leak kernel memory and system file descriptors by invoking system calls with specific argument values, causing the IPNET subsystem to fail to release those resources before the calling application terminates. Per the assessed vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5), an attacker must already be executing code on the device, so this is an availability-only denial-of-service rather than a remote or unauthenticated attack, and there is no confidentiality or integrity impact. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); Wind River has released a fixed version, 26.09, so the primary remediation is a firmware upgrade.
An insufficient buffer-size validation defect in Zephyr RTOS's ADI MAX32 ADC driver (drivers/adc/adc_max32.c) allows a local, low-privileged user-mode thread to write up to twice the length of its supplied buffer into kernel memory, producing attacker-controlled out-of-bounds writes at an attacker-chosen offset. Exploitation requires a build compiled with CONFIG_USERSPACE running on ADI MAX32 hardware where the calling thread has already been granted access to a MAX32 ADC device object; on such a build the attacker fully controls channels, buffer, buffer_size and options->extra_samplings, and the resulting corruption of adjacent memory, kernel data or thread stacks is a plausible local privilege-escalation and denial-of-service primitive (CVSS 7.8, AV:L/PR:L). The flaw is not remotely exploitable, and builds without CONFIG_USERSPACE are reduced to a caller-side robustness defect since the application supplies its own buffer; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
An out-of-bounds kernel-mode write in Zephyr RTOS's NXP MCUX LPADC driver (drivers/adc/adc_mcux_lpadc.c) lets an unprivileged user-mode thread corrupt memory outside its own partition, providing a genuine local privilege-escalation and denial-of-service primitive rather than an inflated high-severity score. The bug affects builds compiled with CONFIG_USERSPACE that use the MCUX LPADC driver in interrupt-driven mode (or DMA-driven mode on releases carrying the DMA path), where adc_read()/adc_read_async() are system calls: a thread already granted access to the LPADC device object controls channels, buffer, buffer_size and options->extra_samplings, and can demand up to channels × 65536 samples into a tiny buffer, causing the driver's ISR or DMA callback to walk past the buffer while running in kernel mode where the MPU does not confine it. No public exploit code or confirmed active exploitation has been identified at time of analysis, but the CVSS vector (7.8, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects high confidentiality and integrity impact from an authenticated local attacker, and upstream fixes are available.
Kernel memory corruption in Zephyr RTOS arises from the RTIO userspace syscall verifier z_vrfy_rtio_sqe_copy_in_get_handles(), which validates the RTIO object handle and the incoming sqes array but never checks that the caller-supplied handle out-parameter is writable before executing *handle = sqe in supervisor mode. Any user-mode thread that has been granted a struct rtio kernel object - the normal situation for applications using sensor_read_async_mempool() or the async ADC helpers, which call rtio_sqe_copy_in_get_handles() internally - can supply an arbitrary destination address and thereby obtain a write-what-where primitive that stores a pointer to attacker-controlled ring data at any kernel location, corrupting function pointers, thread structures or memory-domain partition tables and breaking the CONFIG_USERSPACE isolation boundary. The issue is local-only and build-gated (CVSS 7.8, AV:L/PR:L, CWE-787), requires both CONFIG_USERSPACE and CONFIG_RTIO, and no public exploit code has been identified at time of analysis, although an upstream vendor fix and GitHub security advisory are available.
Memory corruption in Wind River VxWorks 7 occurs when a task passes crafted arguments to a specific system call, causing an out-of-bounds write inside the RTOS memory-management subsystem and giving the caller full confidentiality, integrity, and availability impact on the running instance (CVSS 3.1 7.8 HIGH). The flaw is local in nature - per the vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) the attacker must already execute code on the device as at least a low-privileged task, so only VxWorks 7 deployments that run untrusted or lower-trust code are realistically exposed; locked-down devices that execute only vendor-signed firmware are not remotely reachable through this bug. All VxWorks 7 builds prior to version 26.09 are affected, and there is no public exploit code or CISA KEV entry identified at time of analysis.
An out-of-bounds read in Zephyr's MCUmgr SMP-over-console transport (subsys/mgmt/mcumgr/transport/src/serial_util.c) lets a single 7-byte, unauthenticated console line underflow a net_buf length field and hand the SMP layer a bogus ~65 KB payload window over a buffer whose data area defaults to 384 bytes. The flaw affects builds that enable 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; the test-only CONFIG_MCUMGR_TRANSPORT_DUMMY loopback carries the same pattern but has no external input path and is not exploitable. Because exploitation needs only write access to the management console - on many boards an exposed USB CDC-ACM port rather than a bare UART header - the practical impact is a faulted MCUmgr thread (denial of service) plus possible limited memory disclosure via the default-enabled os echo handler; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Denial of service in the Zephyr RTOS LwM2M client: the CoAP Block1 write handler can be driven into a NULL pointer dereference that crashes or resets the device. Affected are Zephyr builds using the LwM2M engine with block-wise transfer handling, particularly NoSec deployments where CONFIG_LWM2M_DTLS_SUPPORT is disabled (it has no default, so this is a common configuration); an unauthenticated remote peer that can reach the LwM2M UDP socket - an on-path or address-spoofing attacker, or a bootstrap/lower-trust server - first exhausts the static Block1 context pool (CONFIG_LWM2M_NUM_BLOCK1_CONTEXT, default 3) with three incomplete block-wise writes, then sends a fourth first-block write to hit the unguarded store. The assessed impact is availability only (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 5.9), and no public exploit code was identified at time of analysis; the multi-request pool-exhaustion sequence is the main factor keeping complexity high.
Repeated network-interface link-down events can crash or reset devices running Zephyr RTOS v4.3.0 that keep a listening TCP socket open, because the BSD-socket layer parks a pending errno value in the net_context user_data field while the TCP core simultaneously expects that field to hold a parent context pointer; a second interface-down event forwards the stale integer to zsock_accepted_cb(), which dereferences it as a pointer and writes through it, producing a wild-pointer access and a kernel fatal error (denial of service, not attacker-directed memory corruption). The flaw is reachable by unauthenticated adjacent attackers who can force the link down repeatedly (CVSS 3.1 AV:A/AC:L/PR:N/UI:N, 6.5, availability-only impact), and no public exploit code or confirmed active exploitation has been identified at time of analysis. Zephyr v4.3.1 and v4.4.x carry a follow-up change that clears the accept callback after the error path, reducing the issue to a narrow handshake-versus-interface-down race plus an unconditional getsockopt(SO_ERROR) read-back of the kernel pointer stored in user_data, so those lines are far less practically exploitable than v4.3.0.
Local denial of service in Wind River VxWorks 7 (all releases prior to 26.09) lets a low-privileged local task exhaust kernel memory by invoking process-management system calls whose specific arguments cause the subsystem to skip freeing allocated kernel memory when the calling application terminates. Repeated invocation accumulates the leak until the kernel memory pool is depleted, producing a high availability impact (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited; Wind River has fixed it in VxWorks 7 version 26.09.
Memory pool exhaustion in Wind River VxWorks 7 releases 24.03 through 26.03 can terminate system operations when specific service routines are invoked while the device is in a non-default configuration state, because allocated memory pools are not released before the failure propagates. The weakness is local and availability-focused (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H per independent assessment): an attacker needs low-privileged local execution on the RTOS and the affected services must be reachable, and no user interaction or network path is required. Default installations are not affected, the configuration prerequisite plus the local-access requirement substantially narrow the realistic attacker population, and no public exploit identified at time of analysis; Wind River has fixed the issue in VxWorks 7 26.09. Overall this is a moderate-severity, low-real-world-priority issue rather than a broadly exploitable one.
An out-of-bounds read in the Zephyr RTOS CoAP link-format helper match_path_uri() (subsys/net/lib/coap/coap_link_format.c) allows an unauthenticated remote attacker to drive the URI comparison loop one or more bytes past the end of a Uri-Query href= option value by sending a GET /.well-known/core?href=/<prefix> request whose value is a strict prefix of a longer registered resource path. Only devices running the Zephyr CoAP server subsystem with CONFIG_COAP_SERVER_WELL_KNOWN_CORE enabled (the default) and at least one resource declaring struct coap_core_metadata attributes reach the vulnerable code path. The over-read is bounded - in practice a single byte, limited by the compared path length - reads only uninitialized stack tail rather than receive-buffer or attacker-controlled data, cannot influence the response, and yields undefined behaviour rather than information disclosure or a matching error; no public exploit code was identified at time of analysis, and the assessed severity is Low (CVSS 3.7).
A supervisor-mode out-of-bounds write exists in the Zephyr RTOS 802.15.4 L2 transmit path: ieee802154_send() copies packet data into a fixed 125-byte frame buffer without validating the packet length on the unfragmented code path. On builds with CONFIG_NET_L2_IEEE802154_FRAGMENT (enabled by default with CONFIG_NET_6LO), local code that opens a NET_AF_PACKET socket (NET_SOCK_RAW, which skips the 6LoWPAN encoder, or NET_SOCK_DGRAM, which returns early on the address-family check) bound to an 802.15.4 interface can send a payload larger than IEEE802154_MTU and corrupt memory adjacent to the transmit buffer pool, causing a crash or further compromise of kernel state. The flaw is not reachable from the radio because ieee802154_6lo_encode_pkt() length-checks IPv6 packets and forces fragmentation; in a CONFIG_USERSPACE build an unprivileged thread can reach it through the zsock_socket()/zsock_sendto() syscalls, though the overrun is bounded to roughly ll_hdr_len + 3 bytes with the default fixed-size net_buf configuration. No public exploit code was identified at time of analysis and the vendor patch is available (commit 3d4c6177d2dbd77d12d9b14cd75a00cdbd826227).
Local resource exhaustion in Wind River VxWorks 7 (versions prior to 26.09) allows a low-privileged local application to leak kernel memory and system file descriptors by invoking system calls with specific argument values, causing the IPNET subsystem to fail to release those resources before the calling application terminates. Per the assessed vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5), an attacker must already be executing code on the device, so this is an availability-only denial-of-service rather than a remote or unauthenticated attack, and there is no confidentiality or integrity impact. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); Wind River has released a fixed version, 26.09, so the primary remediation is a firmware upgrade.