Vulnerability database
Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.
363 results · page 1 of 8
Oct 28, 2026ethernet_fill_header() in subsys/net/l2/ethernet/ethernet.c can prepend the Ethernet header in place, by pushing it into the headroom of the packet's first fragCVE-2026-82962 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
ethernet_fill_header() in subsys/net/l2/ethernet/ethernet.c can prepend the Ethernet header in place, by pushing it into the headroom of the packet's first fragment, instead of allocating a separate header fragment. Before this fix the in-place path was selected purely from the build-time value of CONFIG_NET_L2_ETHERNET_RESERVE_HEADER, with no check that the packet actually has that headroom, and then called net_buf_push(pkt->buffer, hdr_len). Only Ethernet TX allocations reserve that space: net_pkt_alloc_buffer() invokes the L2 alloc hook (ethernet_l2_alloc()) only when is_pkt_tx() is true and the packet's interface is the Ethernet interface. A packet that was allocated by a different L2 and then handed to Ethernet for transmission therefore has too little (usually zero) headroom. Such packets are produced by ordinary routing and tunnelling paths: net_route_packet_if() re-targets a received packet to another interface when CONFIG_NET_IPV4_FORWARDING / CONFIG_NET_IPV6_FORWARDING are enabled (for example an 802.15.4/OpenThread or PPP interface forwarding to Wi-Fi/Ethernet), net_route_ipv6_mcast_forward_packet() forwards an RX-slab clone that carries no reserve, and the IPIP tunnel
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 28, 2026The GPIO syscall handlers in drivers/gpio/gpio_handlers.c did not validate the pin argument supplied by a user-mode caller.CVE-2026-82961 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The GPIO syscall handlers in drivers/gpio/gpio_handlers.c did not validate the pin argument supplied by a user-mode caller. z_vrfy_gpio_pin_configure(), z_vrfy_gpio_pin_get_config() and z_vrfy_gpio_pin_interrupt_configure() verified only the device object (K_SYSCALL_DRIVER_GPIO() / K_SYSCALL_OBJ()) and then passed the caller-supplied gpio_pin_t straight through to z_impl_gpio_pin_*() and on to the driver. The only pin check in include/zephyr/drivers/gpio.h was __ASSERT(gpio_port_pin_is_supported(cfg->port_pin_mask, pin), ...), which compiles to nothing unless CONFIG_ASSERT is enabled, so in a production build no check existed at all. GPIO drivers use pin as a shift count and as an array index on the documented assumption that it is a pin the controller supports. On STM32, for example, gpio_stm32_pin_interrupt_configure() turns pin into an EXTI line and stm32_gpio_intc_set_irq_callback() writes data->cb[line_num].cb and data->cb[line_num].data into a NUM_EXTI_LINES-entry array (default 16) in drivers/interrupt_controller/intc_gpio_stm32.c, guarded only by a compiled-out __ASSERT_NO_MSG(); the same function then reads exti_irq_table[line_num] and calls irq_enable() on the result. Ot
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 26, 2026The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API — it hands out up to CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (defaCVE-2026-82390 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgLow 3.7
The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API — it hands out up to CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (default 4) independent sessions, each carrying its own key and direction. The AES peripheral, however, has a single chip-global set of key and mode registers, and aes_begin_session() programmed them exactly once, at session start, outside the aes_lock mutex that serialises the transforms. The per-operation handlers aes_ecb_op(), aes_cbc_op() and aes_ctr_op() then ran aes_hal_transform_block() against whatever key and direction the registers happened to hold. As a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session's key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of "each thread does begin, then op, then free on its own session" also races: a second thread's cipher_begin_session() landing between the first thread's begin and its operation makes that operation run under the second thread's key. An attacker who can induce session creation on the device — for examp
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 26, 2026In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfp_ag_create() in subsys/bluetooth/host/classic/hfp_ag.c starts an SDP discovery toward the peeCVE-2026-82389 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfp_ag_create() in subsys/bluetooth/host/classic/hfp_ag.c starts an SDP discovery toward the peer, which links the embedded ag->sdp_param._node into the SDP client's pending request list in subsys/bluetooth/host/classic/sdp.c. If the subsequent bt_rfcomm_dlc_connect() call fails, bt_hfp_ag_connect() cleaned up by memset()-ing the entire AG object while that node was still linked, and while ag->slc_work could still be queued on the system work queue. An in-flight SDP discovery cannot be cancelled — bt_sdp_discover_cancel() is declared in the public header but has no implementation — so the request stays in the list with its func, pool and uuid pointers zeroed. The RFCOMM channel passed to bt_hfp_ag_connect() is taken from the peer's own SDP Hands-Free service record in the normal AG flow (bt_sdp_get_proto_param() performs no range validation, and samples/bluetooth/classic/handsfree_ag feeds the value straight through), so a remote BR/EDR device in radio range that advertises an RFCOMM channel outside the valid range 0x01..0x1e deterministically forces bt_rfcomm_dlc_connect() to fail and reach the wipe. Reading the peer
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 26, 2026bt_hfp_hf_connect() in subsys/bluetooth/host/classic/hfp_hf.c allocates the per-connection HFP Hands-Free object with hfp_hf_create(), which starts an SDP discoCVE-2026-82388 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.3
bt_hfp_hf_connect() in subsys/bluetooth/host/classic/hfp_hf.c allocates the per-connection HFP Hands-Free object with hfp_hf_create(), which starts an SDP discovery by passing the object's embedded hf->sdp_param to bt_sdp_discover(). That call links the caller-owned parameter block into the SDP client's request list (session->reqs in subsys/bluetooth/host/classic/sdp.c). If the subsequent bt_rfcomm_dlc_connect() then failed, the affected code wiped the entire object with (void)memset(new_hf, 0, sizeof(*new_hf)) while that discovery was still outstanding, zeroing the sys_snode_t _node that is still linked in the SDP client's list along with the request's func, uuid and pool pointers, and zeroing the hf->slc_work work item that may already be queued on the system workqueue. The discovery could not be retracted instead: bt_sdp_discover_cancel() is declared in include/zephyr/bluetooth/classic/sdp.h but has no implementation. The failing branch is reachable with peer-supplied input. The documented use of bt_hfp_hf_connect() is to pass the RFCOMM channel read out of the remote Audio Gateway's SDP record; neither bt_sdp_get_proto_param() nor bt_hfp_hf_connect() range-checks that value, s
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 26, 2026The Bluetooth host pre-allocates a bt_conn object (a "reservation") from the fixed acl_conns[] pool for every connectable advertising set it starts, in le_adv_sCVE-2026-81039 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 4.3
The Bluetooth host pre-allocates a bt_conn object (a "reservation") from the fixed acl_conns[] pool for every connectable advertising set it starts, in le_adv_start_add_conn() in subsys/bluetooth/host/adv.c. When an incoming peripheral connection completes, find_pending_connect() in subsys/bluetooth/host/hci_core.c looked that reservation up using only the identity and the peer address, with a directed-then-undirected fallback, and had no knowledge of which advertising set actually terminated. With CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1, where the LE Enhanced Connection Complete event is cached until the LE Advertising Set Terminated event identifies the set, this lookup can return the reservation belonging to a different, still-running advertising set. The defect is reachable over the air by any adjacent device. If an application runs two connectable extended advertising sets on the same identity — one undirected and one directed at a peer P (the common "directed reconnect to a bonded central while still accepting new centrals" pattern) — a remote initiator whose address maps to P connecting on the undirected set causes the directed set's reservation to be consumed instead. The initia
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 26, 2026The Object Transfer Service server builds its Object Action Control Point (OACP) response indication in oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.CVE-2026-81038 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.1
The Object Transfer Service server builds its Object Action Control Point (OACP) response indication in oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.c). Before this fix the four-byte Checksum Value field was appended whenever the requested op code was BT_GATT_OTS_OACP_PROC_CHECKSUM_CALC, regardless of the result code. The response payload is a bare, uninitialized four-byte stack buffer declared with NET_BUF_SIMPLE_DEFINE(resp_param, sizeof(uint32_t)) in bt_gatt_ots_oacp_write(), and it is filled only on the success path of oacp_checksum_proc_validate(). On every failure path the buffer is still empty, so net_buf_simple_pull_le32() was invoked on a zero-length buffer. The OACP characteristic and its client characteristic configuration descriptor are declared with BT_GATT_PERM_WRITE and BT_GATT_PERM_READ | BT_GATT_PERM_WRITE, so no pairing, encryption, or authentication is required. Any peer within radio range that can connect to a device running the OTS server can enable OACP indications and write a nine-byte Calculate Checksum command that fails validation — for example by issuing it with no object selected, which returns BT_GATT_OTS_OACP_RES_INV_OBJ. Because oacp_comma
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 26, 2026The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (gen_stable_iid() in subsys/net/ip/ipv6.c) and RFC 8981 tCVE-2026-19742 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgLow 3.7
The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (gen_stable_iid() in subsys/net/ip/ipv6.c) and RFC 8981 temporary interface identifiers (gen_temporary_iid() in subsys/net/ip/ipv6_pe.c) with sys_rand_get(). That API is documented as not cryptographically secure, while both RFCs require this key to be an unpredictable random value of at least 128 bits — the unpredictability of every generated IID rests entirely on it. Depending on the platform, sys_rand_get() resolves either to a hardware entropy device or, on boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, to the non-cryptographic xoshiro128++ generator in subsys/random/random_xoshiro128.c, which keeps a single global 128-bit state shared with every other sys_rand_get() consumer. Many of those consumers put their output directly on the wire (ephemeral source ports, DNS query IDs, CoAP message IDs and tokens, DHCPv6 transaction IDs, WebSocket masking keys), and the xoshiro state transition is invertible, so an observer of a device's traffic can recover the generator state and reconstruct the IID secret key. Additionally, with the entropy-device backend sys_rand_get()
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 23, 2026The Bluetooth HCI USB transport class of the new USB device stack, subsys/usb/device_next/class/bt_hci.c, copies every controller-to-host HCI packet into a USB CVE-2026-79982 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 8.8
The Bluetooth HCI USB transport class of the new USB device stack, subsys/usb/device_next/class/bt_hci.c, copies every controller-to-host HCI packet into a USB transfer buffer before enqueuing it on an endpoint. bt_hci_tx_sync_in() allocated that buffer from bt_hci_ep_pool, a fixed pool whose slots are only USBD_MAX_BULK_MPS bytes (64 on full-speed-only builds), and then performed net_buf_add_mem(buf, bt_buf->data, bt_buf->len) with no length check. HCI event and ACL buffers are sized by CONFIG_BT_BUF_EVT_RX_SIZE and CONFIG_BT_BUF_ACL_RX_SIZE and can be far larger, so the copy runs past the end of the 64-byte slot into the adjacent slots and into whatever follows the statically allocated pool. The device runs the local Bluetooth controller in raw HCI mode (CONFIG_BT_HCI_RAW), so the oversized packets originate over the air. With the HCI buffer sizes recommended for full-featured controllers, an unauthenticated attacker within Bluetooth range can supply the overflowing bytes: a connected peer that negotiates Data Length Extension can send ACL fragments up to CONFIG_BT_CTLR_DATA_LENGTH_MAX bytes, and an attacker that merely broadcasts extended advertising data reaches the same path
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 23, 2026The DNS stub resolver in subsys/net/lib/dns/resolve.c binds one UDP socket per configured server when the resolver context is initialised (dns_resolve_init_lockCVE-2026-79981 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
The DNS stub resolver in subsys/net/lib/dns/resolve.c binds one UDP socket per configured server when the resolver context is initialised (dns_resolve_init_locked() -> register_dispatcher() -> dns_dispatcher_register()), with the local port left at 0 so the stack picks an ephemeral port exactly once. dns_write() then sends every subsequent query from that same socket without re-binding, so the source port is constant for the lifetime of the resolver context while only the 16-bit transaction identifier (ctx->queries[i].id, drawn with sys_rand16_get()) varies per query. RFC 5452 section 9.2 requires both to vary; with a fixed port, an off-path attacker has to guess only the identifier. The stable port is cheap to learn. Any single observed query reveals it permanently, and it can also be found by probing the ephemeral UDP range: subsys/net/ip/connection.c answers unmatched unicast UDP with an ICMP port-unreachable, so the resolver's socket is the one port in that range that stays silent. Acceptance of a reply is decided solely by get_slot_by_id() matching the transaction identifier and a CRC-16 of the queried name — the reply's source address is never checked (dispatcher_cb() does A
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 23, 2026The DHCPv4 client in subsys/net/lib/dhcpv4/dhcpv4.c maintained its transaction identifier (iface->config.dhcpv4.xid) as a counter rather than as a per-transactiCVE-2026-79980 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.6
The DHCPv4 client in subsys/net/lib/dhcpv4/dhcpv4.c maintained its transaction identifier (iface->config.dhcpv4.xid) as a counter rather than as a per-transaction random value. It was seeded once with sys_rand32_get() in dhcpv4_start_internal(), incremented by one in dhcpv4_send_discover() and dhcpv4_send_decline(), and never changed by dhcpv4_send_request() — so every RENEWING and REBINDING exchange reused, unchanged, the identifier that had already appeared on the wire in the broadcast DHCPDISCOVER at boot, and where the identifier did move it moved predictably by one. RFC 2131 4.1 requires a single identifier per transaction, chosen so that clients are unlikely to collide. This identifier is the client's only unpredictable reply-validation token. net_dhcpv4_input() accepts a BOOTP reply on op, a matching xid, and a matching chaddr (the interface MAC, which is public); the UDP callback is registered with a wildcard remote address and port, and no server-identifier or source-address check is applied. An attacker who learns one identifier — for example any host on the same segment that sees the broadcast DHCPDISCOVER, or a DHCP server or relay on a network the device previously jo
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 23, 2026The arm64 MMU backend invalidates a single virtual address from the TLB with invalidate_tlb_page() in arch/arm64/core/mmu.c, which issued TLBI VAE1{IS} with an CVE-2026-79979 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The arm64 MMU backend invalidates a single virtual address from the TLB with invalidate_tlb_page() in arch/arm64/core/mmu.c, which issued TLBI VAE1{IS} with an operand of virt >> 12. That operand encodes the ASID in bits [63:48], so the invalidation only ever matched ASID 0 (the kernel page tables) and global entries. Memory domains, however, are allocated ASIDs starting at 1 in arch_mem_domain_init(), and every domain-private leaf created by private_map() is mapped with MT_NG, i.e. non-global. A domain's cached translation therefore survived the invalidation. All callers of invalidate_tlb_page() are demand-paging paths. When the eviction algorithm reclaims a frame, page_frame_prepare_locked() in kernel/mmu.c calls arch_mem_page_out(), which marks the kernel leaf invalid, propagates the invalid descriptor into every domain via sync_domains(), and then flushes only ASID 0. do_page_fault() immediately reuses the very same page frame for the incoming mapping through arch_mem_page_in(). A user thread that had already touched the evicted page — a k_mem_partition added with arch_mem_domain_partition_add(), or its own stack mapped by map_thread_stack() — retains a valid EL0 read/write tr
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 23, 2026The RTIO streaming completion callback adxl345_process_fifo_samples_cb() in drivers/sensor/adi/adxl345/adxl345_stream.c clamps the amount of FIFO data it will rCVE-2026-79978 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgLow 3.6
The RTIO streaming completion callback adxl345_process_fifo_samples_cb() in drivers/sensor/adi/adxl345/adxl345_stream.c clamps the amount of FIFO data it will report (read_len = MIN(fifo_bytes, buf_avail)) to the space actually returned by rtio_sqe_rx_buf(), but then queues one 6-byte bus read per hardware FIFO entry at consecutive offsets from read_buf, bounded by the device-reported entry count rather than by the clamp. When the allocated buffer is smaller than a full batch, the driver writes up to 186 bytes past the end of the allocation; a companion defect left data->fifo_total_bytes un-reset at batch start, so an aborted or errored chain could leave a stale write offset that pushes the next batch's writes out of bounds as well. A short buffer is an expected, first-class outcome of the RTIO allocator: rtio_block_pool_alloc() walks the requested size down one block at a time until a contiguous run is available, and the driver only demands sizeof(struct adxl345_fifo_data) + 6 bytes as its minimum. Any streaming configuration whose mempool block granularity is smaller than a full FIFO batch (204 bytes) — for example the sensor shell's RTIO_DEFINE_WITH_MEMPOOL(sensor_read_rtio, 8,
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 23, 2026The WireGuard VPN service in subsys/net/lib/wireguard/wg.c updated the peer endpoint from a message it could not authenticate.CVE-2026-79977 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 8.2
The WireGuard VPN service in subsys/net/lib/wireguard/wg.c updated the peer endpoint from a message it could not authenticate. In handle_transport_data(), when the 32-bit receiver index of an incoming transport-data message matched no session, the code both scheduled a new handshake and copied the datagram's source address into peer->endpoint with memcpy(&peer->endpoint, peer_addr, sizeof(peer->endpoint)). Because the receiver index is unknown, there is no key with which such a message could be verified, so the address written into peer->endpoint is entirely attacker-supplied. Every other endpoint update in the implementation happens only after authentication — after the Noise handshake in handle_handshake_init(), or after AEAD decryption plus the anti-replay check in wg_process_data_message(). The WireGuard listener is registered with net_udp_register() using no remote address or port filter and defaults to UDP port 51820 (CONFIG_WIREGUARD_PORT), and wg_ctrl_recv() resolves the peer by interface rather than by any cryptographic identity. Any host able to send a UDP datagram to that port can therefore reach the defect off-path, with no need to observe legitimate traffic: a 16-byte
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 23, 2026Zephyr's OpenThread integration defined CONFIG_OPENTHREAD_JOINER_PSKD with default "J01NME" in modules/openthread/Kconfig.thread (previously subsys/net/l2/opentCVE-2026-19741 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.5
Zephyr's OpenThread integration defined CONFIG_OPENTHREAD_JOINER_PSKD with default "J01NME" in modules/openthread/Kconfig.thread (previously subsys/net/l2/openthread/Kconfig, then subsys/net/l2/openthread/Kconfig.thread). J01NME is the example Joining Device Credential used throughout the public OpenThread and Thread commissioning documentation, including Zephyr's own samples/net/sockets/echo_client/README.rst, so it is not a secret. A firmware image built with CONFIG_OPENTHREAD_JOINER_AUTOSTART=y that never overrode the PSKd therefore shipped with a publicly known joining credential compiled in, with no build-time or run-time warning. The PSKd is the only value that authenticates Thread commissioning: joiner and commissioner run a DTLS-PSK handshake keyed on it, after which the commissioner supplies the full operational dataset. In ot_configure_instance() (modules/openthread/openthread.c), a device with no stored dataset calls otJoinerStart() with the configured PSKd, and ot_joiner_start_handler() calls otThreadSetEnabled() on success. An unauthenticated attacker within 802.15.4 radio range of an uncommissioned device (factory-fresh, after a factory reset, or after a settings era
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The MCTP-over-I2C+GPIO target binding in subsys/pmci/mctp/mctp_i2c_gpio_target.c emulates a small pseudo-register file, where the bus controller first writes a CVE-2026-79976 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.1
The MCTP-over-I2C+GPIO target binding in subsys/pmci/mctp/mctp_i2c_gpio_target.c emulates a small pseudo-register file, where the bus controller first writes a register number and then writes or reads payload bytes. The selected register (b->reg_addr) and the data-phase flag (b->rxtx) were never cleared when the controller issued an I2C STOP, so after a completed transfer the target still had a data register selected while the packet buffer that register refers to had already been consumed and set to NULL by mctp_i2c_gpio_target_stop(). A controller on the bus can re-enter the same branch of mctp_i2c_gpio_target_stop() with a NULL buffer using two ordinary transactions and no authentication: first a normal packet write to MCTP_I2C_GPIO_RX_MSG_ADDR followed by STOP (which delivers and frees b->rx_pkt), then a bare read transaction followed by STOP. The failing read_requested() call leaves the stale state untouched and the I2C driver still delivers the STOP callback, which then calls mctp_bus_rx() with a NULL packet. The symmetric case exists on the transmit side, where the stale MCTP_I2C_GPIO_TX_MSG_ADDR selection dereferences b->tx_pkt->end after b->tx_pkt has been cleared and add
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The Nuvoton NPCX eSPI driver parses Target-Attached-Flash (TAF) requests in espi_taf_parse() (drivers/espi/espi_npcx.c), taking the 12-bit length field directlyCVE-2026-78119 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.3
The Nuvoton NPCX eSPI driver parses Target-Attached-Flash (TAF) requests in espi_taf_parse() (drivers/espi/espi_npcx.c), taking the 12-bit length field directly out of the request header in the FLASHRXBUF FIFO. For write and RPMC OP1 requests it copied DIV_ROUND_UP(len, 4) words into struct espi_taf_pckt.src, a fixed 16-word (64-byte) member of a static structure, without ever comparing the length against that buffer or against the negotiated eSPI receive payload size (rx-plsize, 64 bytes on all in-tree NPCX/NPCK SoCs). Both the loop counter and the word count were uint8_t, so the copy ran up to 255 iterations. An eSPI controller that emits a flash request whose header claims a payload larger than the negotiated maximum therefore drives up to 239 32-bit stores past the end of the structure — roughly 956 bytes of out-of-bounds write into .bss — from the eSPI flash receive interrupt handler, while the source reads walk past the end of the 18-word FLASHRXBUF register array into neighbouring eSPI registers. The same unvalidated length was then passed on to flash_write() in espi_taf_npcx_flash_write() with the 64-byte src buffer as source, reading up to 4 KB of adjacent controller SRAM
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The kernel helper z_waitq_head() (kernel/include/wait_q.h) reads the head of a thread wait queue, but on SMP systems it was called from several places without hCVE-2026-78118 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7
The kernel helper z_waitq_head() (kernel/include/wait_q.h) reads the head of a thread wait queue, but on SMP systems it was called from several places without holding the scheduler spinlock _sched_spinlock that serializes wait-queue mutation. The consequential call site is z_timer_expiration_handler() in kernel/timer.c, which held only the timer subsystem lock timer_lock while reading timer->wait_q and then unpending, setting the return value of, and readying the thread it obtained. halt_thread() in kernel/sched.c removes an aborted thread from its wait queue while holding only _sched_spinlock, so the two paths are not mutually exclusive. When the last waiter is removed on another CPU inside that window, sys_dlist_peek_head() can return the list sentinel — a pointer into the k_timer object itself — typed as a struct k_thread * (with CONFIG_WAITQ_SCALABLE, rb_get_min() can return an arbitrary node of a tree being restructured), or it can return a pointer to a thread that has already been unpended and, for dynamically allocated threads, freed. The handler then calls unpend_thread_no_timeout(), which performs a sys_dlist_remove() through pointers read from that object, and arch_threa
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The Infineon PSOC 6 BLESS HCI driver in drivers/bluetooth/hci/hci_infineon_psoc6_bless.c stored the outgoing HCI packet descriptor in a file-scope variable, staCVE-2026-78117 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 4.2
The Infineon PSOC 6 BLESS HCI driver in drivers/bluetooth/hci/hci_infineon_psoc6_bless.c stored the outgoing HCI packet descriptor in a file-scope variable, static cy_stc_ble_hci_tx_packet_info_t hci_tx_pkt. psoc6_bless_send() cleared and populated that descriptor's packetType, dataLength and data fields before acquiring psoc6_bless_operation_sem, so the driver's serialising semaphore protected only the call into Cy_BLE_SoftHciSendAppPkt() and not the shared state that call reads. The Bluetooth host does not guarantee a single HCI sender. Most transmissions are funnelled through the cooperative TX-processor work queue, but bt_hci_cmd_send() deliberately bypasses bt_dev.cmd_tx_queue for BT_HCI_OP_HOST_NUM_COMPLETED_PACKETS and calls bt_send() directly from the caller's thread; that caller is bt_hci_host_num_completed_packets(), the acl_in_pool destroy callback, which runs on whichever thread drops the last reference to a received ACL buffer. CONFIG_BT_HCI_ACL_FLOW_CONTROL defaults to y on this driver's boards, and an application that returns -EINPROGRESS from its L2CAP recv callback and later calls bt_l2cap_chan_recv_complete() performs that unref from its own preemptible thread. A
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The Broadcom AFBR-S50 time-of-flight sensor driver double-completes an RTIO submission when sensor data evaluation fails.CVE-2026-78116 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.2
The Broadcom AFBR-S50 time-of-flight sensor driver double-completes an RTIO submission when sensor data evaluation fails. In data_ready_work_handler() (drivers/sensor/broadcom/afbr_s50/afbr_s50.c), a non-STATUS_OK return from Argus_EvaluateData() calls handle_error_on_result(), which finalises the request with rtio_iodev_sqe_err(), but execution then fell through to the tail of the function and finalised the very same struct rtio_iodev_sqe a second time with rtio_iodev_sqe_ok(). Unlike the other error branches in the same function, this one did not return. Both completion helpers reach rtio_executor_done() in subsys/rtio/rtio_executor.c, which returns the submission to the pool via rtio_sqe_pool_free() and, for streaming (multishot) submissions, also releases the RX buffer with rtio_release_buffer(). The second completion therefore reads a freed rtio_iodev_sqe, pushes the same mpsc node onto the submission queue while it is already on the pool free list — splicing the two lists together — and re-submits the freed request so the next measurement is written through an already-released buffer. For one-shot submissions it emits a spurious success completion carrying stale userdata and
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmux_select_get() and devmux_select_set().CVE-2026-19947 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.3
The device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmux_select_get() and devmux_select_set(). When CONFIG_USERSPACE is enabled, their user-mode verifiers z_vrfy_devmux_select_get() and z_vrfy_devmux_select_set() forwarded directly to the kernel implementations without performing any kernel-object validation — no k_object_access_check() and no driver object check. Compounding this, DEVICE_DT_INST_DEFINE() registered devmux instances with a NULL driver API pointer, which causes scripts/build/gen_kobject_list.py to skip them entirely, so a devmux device had no struct k_object and no permission on it could be granted or withheld in the first place. Any thread running in user mode can reach the defect: device pointers such as DEVICE_DT_GET(DT_NODELABEL(devmux0)) are compile-time constants available to application code, and the syscall accepted them from a thread that had never been granted access to the device. The kernel implementations do validate the pointer against the static devmux instance table and bounds-check the selection index, so this is not a memory-safety issue; the failure is purely one of authorization. Exposure requires CON
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The user-mode verifier for the peci_transfer() system call, z_vrfy_peci_transfer() in drivers/peci/peci_handlers.c, checked only the device object permission anCVE-2026-19676 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The user-mode verifier for the peci_transfer() system call, z_vrfy_peci_transfer() in drivers/peci/peci_handlers.c, checked only the device object permission and copied the caller-supplied struct peci_msg with k_usermode_from_copy(). That copy validates the outer structure only; the buf pointers and len values inside the embedded struct peci_buf members tx_buffer and rx_buffer remained fully caller-controlled and were passed unchecked to the driver. Every in-tree PECI driver dereferences those pointers in supervisor mode: peci_npcx_transfer() in drivers/peci/peci_npcx.c and peci_it8xxx2_transfer() in drivers/peci/peci_ite_it8xxx2.c copy hardware bytes into rx_buffer.buf[i] and read command bytes out of tx_buffer.buf[i], and peci_xec_read()/peci_xec_write() in drivers/peci/peci_mchp_xec.c do the same with no bound on rx_buffer.len at all. A user-mode thread that has been granted the PECI device object — the normal way an application exposes a device under CONFIG_USERSPACE — could therefore point rx_buffer.buf at kernel data structures and have the driver write hardware-supplied bytes there, or point tx_buffer.buf at kernel memory and have its contents pushed onto the PECI/eSPI out-
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 21, 2026The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bt_a2dp_codec_ie, a one-byte len field plus a fixed 8-byte codec_ie[] array.CVE-2026-18748 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgLow 3.5
The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bt_a2dp_codec_ie, a one-byte len field plus a fixed 8-byte codec_ie[] array. When an AVDTP peer sent a codec IE longer than 8 bytes, a2dp_process_config_ind() in subsys/bluetooth/host/classic/a2dp.c copied only the first 8 bytes but assigned the full, attacker-chosen length to len, and then persisted that inconsistent structure into the application's struct bt_a2dp_stream via stream->codec_config. bt_a2dp_get_config_cb() and bt_a2dp_set_config_cb() had the same truncate-the-copy-but-keep-the-length pattern. Every later consumer trusts len. In particular the responder for an incoming AVDTP GET_CONFIGURATION, a2dp_get_config_ind(), executes net_buf_add_mem(rsp_buf, &ep->stream->codec_config.codec_ie[0], ep->stream->codec_config.len), so a paired BR/EDR peer that first sends a SET_CONFIGURATION carrying an oversized codec IE and then requests the configuration back causes the stack to read up to roughly 245 bytes past the end of the 8-byte array and transmit them in the response. codec_config is the last member of struct bt_a2dp_stream, so the read runs into memory adjacent to the application's stream o
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 19, 2026The Bluetooth Classic Hands-Free Profile HF role in subsys/bluetooth/host/classic/hfp_hf.c does not release the AT command buffers that are still queued on hf->CVE-2026-77684 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.7
The Bluetooth Classic Hands-Free Profile HF role in subsys/bluetooth/host/classic/hfp_hf.c does not release the AT command buffers that are still queued on hf->tx_pending when the RFCOMM DLC goes down. hfp_hf_disconnected() only cancelled the work items and cleared hf->acl, and no other code path ever dequeues those buffers, so each one is permanently lost from the fixed hf_pool (CONFIG_BT_MAX_CONN + 1 buffers, i.e. two in the default configuration). The same function also left BT_HFP_HF_FLAG_CONNECTED set, and hfp_hf_create() wiped the object with memset() as soon as hf->acl was NULL, without checking whether hf->work, hf->slc_work or hf->deferred_work was still pending or running. The remote Audio Gateway peer controls the trigger end to end and needs no application involvement: an unsolicited +BCS: 1 response makes bcs_handle() call bt_hfp_hf_select_codec() and queue an AT+BCS buffer, which cannot be transmitted while BT_HFP_HF_FLAG_RX_ONGOING is set, and an immediately following RFCOMM DISC strands that buffer. Repeating the connect / +BCS / disconnect cycle a couple of times empties hf_pool for good. With the pool exhausted, HFP command sending fails permanently, and because
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 19, 2026The user-mode syscall verifier z_vrfy_rtio_cqe_get_mempool_buffer() in subsys/rtio/rtio_syscalls.c validated its two output parameters, buff and buff_len, with CVE-2026-19595 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.1
The user-mode syscall verifier z_vrfy_rtio_cqe_get_mempool_buffer() in subsys/rtio/rtio_syscalls.c validated its two output parameters, buff and buff_len, with K_SYSCALL_MEMORY_READ() rather than K_SYSCALL_MEMORY_WRITE(). Both are pure out-parameters: z_impl_rtio_cqe_get_mempool_buffer() stores the mempool buffer address and its length through them. The distinction is enforced by every architecture validator — arch_buffer_validate() on RISC-V PMP explicitly accepts the global __rom_region/__rodata_region for reads only, and the ARM MPU validators accept P_RO_U_RO and P_RW_U_RO regions for reads only — so a read-validated pointer is not necessarily writable by the calling thread. An unprivileged user-mode thread that has been granted access to an RTIO context (rtio_access_grant()) can invoke the rtio_cqe_get_mempool_buffer() syscall with buff/buff_len pointing at memory it may read but not write, and with a completion-queue entry whose flags field it fully controls (only RTIO_CQE_FLAG_MEMPOOL_BUFFER in flags[7:0] is required; flags[19:8] and flags[31:20] supply the block index and count). The kernel then performs a pointer-sized and a 4-byte store through those addresses while runn
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 19, 2026The OSDP Control Panel reply parser cp_decode_response() in subsys/mgmt/osdp/src/osdp_cp.c decodes replies from a Peripheral Device into a stack-allocated strucCVE-2026-76788 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 8.8
The OSDP Control Panel reply parser cp_decode_response() in subsys/mgmt/osdp/src/osdp_cp.c decodes replies from a Peripheral Device into a stack-allocated struct osdp_event. For the REPLY_KEYPPAD and REPLY_RAW reply types, the payload length is taken from the received frame and the only validation performed is that the declared length is self-consistent with the number of payload bytes present in the frame. Because the attacker controls both the length field and the frame length, that check imposes no bound, and the subsequent memcpy() writes into the fixed 64-byte data arrays of struct osdp_event_keypress / struct osdp_event_cardread (OSDP_EVENT_MAX_DATALEN). The sibling REPLY_FMT handler in the same switch already carried the missing > OSDP_EVENT_MAX_DATALEN bound. The defect is reached from cp_process_reply(), which reads bytes from the OSDP RS-485 channel and passes them through osdp_phy_check_packet() and osdp_phy_decode_packet() before dispatching on the reply ID. Triggering it requires CONFIG_OSDP with CONFIG_OSDP_MODE_CP and an application event callback registered (the normal Control Panel integration), plus a frame carrying a correct SOM, a valid CRC-16, and a matching 2
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 19, 2026The UpdateHub firmware-over-the-air client parses the CoAP probe response with Zephyr's JSON library in z_impl_updatehub_probe() (subsys/mgmt/updatehub/updatehuCVE-2026-76787 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.9
The UpdateHub firmware-over-the-air client parses the CoAP probe response with Zephyr's JSON library in z_impl_updatehub_probe() (subsys/mgmt/updatehub/updatehub.c). The decoder treats every descriptor field as optional — json_obj_parse() returns a bitmask of the fields it actually decoded and never fails on a missing one — so a response that omits the "sha256sum" string leaves the corresponding const char * in the zero-initialised struct resp_probe_any_boards / struct resp_probe_some_boards at NULL. Both metadata branches then computed sha256size = strlen(...objects.sha256sum) + 1 before any validation, dereferencing that NULL pointer; the SHA256_HEX_DIGEST_SIZE test that follows operates on a value the bad read has already produced and cannot prevent it. The metadata is supplied entirely by the network peer: probe_cb() accepts the datagram, runs coap_packet_parse() and copies the payload with no token matching and no cryptographic check. With CONFIG_UPDATEHUB_DTLS unset — the default — start_coap_client() uses plain CoAP over UDP on port 5683 with no peer authentication and resolves the server via unauthenticated DNS, so an on-path attacker, a DNS spoofer, or an off-path attacke
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 14, 2026The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame->length - IEECVE-2026-75085 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 4.2
The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame->length - IEEE802154_FCS_LENGTH without first checking that the radio-reported length could hold an FCS. pkt_len is a uint8_t, so a reported length of 0 or 1 wrapped to 254 or 255. The only bound on the resulting value was __ASSERT_NO_MSG(pkt_len <= CONFIG_NET_BUF_DATA_SIZE), which compiles to nothing in the default production configuration (CONFIG_ASSERT=n). The length originates in the ST link-layer receive-done metadata (p_metadata->length, stored by stm32wba_802154_receive_done()), and ultimately in the PHY header of a frame received over the air, so it is influenced by any attacker within radio range of the device. Reaching the underflow requires the vendor link layer to surface a frame shorter than the FCS with no error; the driver performed no validation of its own on that value. When the underflow occurs, stm32wba_802154_rx_thread() calls net_pkt_write(pkt, rx_frame->psdu, pkt_len) with a length of about 254 bytes against a receive buffer that holds at most one PHY packet (IEEE802154_MAX_PHY_PACKET_SIZE, 127 bytes). This reads
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 14, 2026The CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio's RX FIFO in get_packet_length() and validates it in verifyCVE-2026-75084 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.8
The CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio's RX FIFO in get_packet_length() and validates it in verify_rxfifo_validity() (drivers/ieee802154/ieee802154_cc1200.c). That validation only enforced a lower bound (pkt_len < 3); its second clause rejects a FIFO that holds more bytes than declared and therefore never bounds large values. Because the driver configures the radio for variable packet length with PKT_LEN = 0xFF, the length byte is an over-the-air value of 0-255 that reached net_pkt_rx_alloc_with_buffer() and the subsequent SPI burst read unclamped. An unauthenticated attacker within radio range can transmit a frame that presents a length byte above the IEEE 802.15.4 maximum of 127 while the chip's 128-byte RX FIFO has not overflowed, so the driver's RX_FIFO_ERROR pre-check does not fire. Reaching this state depends on RF framing and timing, since the RX thread is driven off the PKT_SYNC_RXTX signal and may sample the FIFO before a packet is complete; no pairing, authentication, or user interaction is required. With the default CONFIG_NET_BUF_FIXED_DATA_SIZE and CONFIG_NET_BUF_DATA_SIZE=128, an allocation larger than on
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 14, 2026The receive path of the NXP KW41Z IEEE 802.15.4 driver, kw41z_rx() in drivers/ieee802154/ieee802154_kw41z.c, computed the payload size as pkt_len = len - KW41Z_CVE-2026-75083 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.9
The receive path of the NXP KW41Z IEEE 802.15.4 driver, kw41z_rx() in drivers/ieee802154/ieee802154_kw41z.c, computed the payload size as pkt_len = len - KW41Z_FCS_LENGTH in a uint8_t, where len is the frame length reported by the radio. The interrupt handler kw41z_isr() obtained that length from the RX_FRAME_LENGTH field of the ZLL IRQSTS register — a copy of the PHY header length byte of the frame received over the air — and only rejected the value zero. A reported length of one therefore underflowed to pkt_len == 255. Because the packet is allocated with NET_AF_UNSPEC on a non-Ethernet L2, net_pkt_rx_alloc_with_buffer() does not clamp the request to the interface MTU; with the default fixed-size buffer pool (CONFIG_NET_BUF_FIXED_DATA_SIZE, CONFIG_NET_BUF_DATA_SIZE=128) the allocation succeeded as a chain of two fragments. The subsequent register-to-buffer copy loops write into the first fragment only, so 255 bytes were written into a 128-byte net_buf data block, overrunning it by up to 127 bytes into adjacent network-buffer-pool memory, and reading up to 128 bytes past the end of the radio's PKT_BUFFER_RX register array. The length field originates from an unauthenticated fram
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 14, 2026ethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr.CVE-2026-19673 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.1
ethernet_recv() in subsys/net/l2/ethernet/ethernet.c validates only that the first net_buf of a received frame holds a plain 14-byte struct net_eth_hdr. When the ethertype is 0x8100 and VLAN is enabled on the interface, the same buffer is reinterpreted as the 18-byte struct net_eth_vlan_hdr without re-checking the length: the VLAN TCI and the inner ethertype are read from offsets 14..17, past pkt->buffer->len, and hdr_len is raised to 18 so the subsequent net_buf_pull() removes more bytes than the buffer holds. A single unauthenticated frame of 14 to 17 bytes carrying the VLAN ethertype triggers this. No knowledge of the node's VLAN configuration is needed: net_eth_get_vlan_iface() returns the base interface for the priority tag 0, and a broadcast destination address satisfies the "frame is for me" test, so a 16-byte broadcast frame with ethertype 0x8100 and TCI 0x0000 reaches the pull. Nothing in the receive path enforces the 60-byte Ethernet minimum — the USB CDC ECM and CDC NCM gadget classes in particular hand host-supplied frames of any non-zero length straight to net_recv_data(). With assertions enabled, net_buf_simple_pull() asserts and the node panics. In a production bui
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026The Bluetooth Classic Hands-Free Profile Audio Gateway implementation in subsys/bluetooth/host/classic/hfp_ag.c keeps its struct bt_hfp_ag objects in a static pCVE-2026-19940 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
The Bluetooth Classic Hands-Free Profile Audio Gateway implementation in subsys/bluetooth/host/classic/hfp_ag.c keeps its struct bt_hfp_ag objects in a static pool indexed by ACL connection index. On link teardown, hfp_ag_disconnected() cancels ag->tx_work and the per-call work items and then clears ag->acl_conn, which marks the pool slot as free — but it leaves ag->ongoing_call_work (and ag->slc_work) untouched. The next connection that lands on the same slot enters hfp_ag_create(), whose only occupancy test is ag->acl_conn, and immediately executes memset(ag, 0, sizeof(struct bt_hfp_ag)) followed by k_work_init_delayable(). Zeroing and re-initialising a k_work_delayable whose struct _timeout node is still linked into the kernel timeout list leaves the kernel holding a reference to a node with NULL prev/next links. ag->ongoing_call_work is armed by the remote peer: when a Hands-Free unit sends AT+CIND? during Service Level Connection establishment and the application provides the asynchronous get_ongoing_call callback, the AG schedules the work for CONFIG_BT_HFP_AG_GET_ONGOING_CALL_TIMEOUT milliseconds (default 10000). The timer is cancelled only if the application answers in tim
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 13, 2026The AVDTP signalling layer arms a 6-second command timeout (AVDTP_TIMEOUT) in avdtp_send_cmd() whenever the local device issues an AVDTP request.CVE-2026-19939 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.3
The AVDTP signalling layer arms a 6-second command timeout (AVDTP_TIMEOUT) in avdtp_send_cmd() whenever the local device issues an AVDTP request. Every response handler in subsys/bluetooth/host/classic/avdtp.c cancels session->timeout_work before clearing the pending request, but bt_avdtp_l2cap_disconnected() only cleared session->req and left the delayable work armed. The struct bt_avdtp session is the first member of struct bt_a2dp, whose instances live in a static per-connection array, and a2dp_get_connection() in subsys/bluetooth/host/classic/a2dp.c wipes a slot with memset() as soon as session->br_chan.chan.conn is NULL — which the L2CAP layer arranges immediately after the disconnect callback returns. A remote Bluetooth BR/EDR peer triggers the condition by opening the AVDTP signalling channel, letting the local application issue an AVDTP procedure (the standard A2DP flow issues bt_a2dp_discover() from the connected callback), then tearing the signalling channel down without responding and re-opening it within the remaining timeout window. The reconnect reaches a2dp_accept() → a2dp_get_connection(), which zeroes the whole struct bt_a2dp while the work item's struct _timeout
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 12, 2026The Bluetooth host's ATT transmit path releases a buffer it does not own when signing fails.CVE-2026-19938 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.9
The Bluetooth host's ATT transmit path releases a buffer it does not own when signing fails. chan_send() in subsys/bluetooth/host/att.c documents (and every other error exit implements) the contract that on failure the caller retains ownership of the net_buf; the BT_ATT_OP_SIGNED_WRITE_CMD branch instead called net_buf_unref(buf) when bt_smp_sign() returned an error and then returned that error to the caller. The callers act on the contract: process_queue() re-queues the buffer with k_queue_prepend(), bt_att_chan_send_rsp() puts it back on chan->tx_queue, bt_att_chan_req_send() restores it into the request, and att_req_retry() unreferences it — so the already-freed buffer was re-queued, later dereferenced, and eventually freed again. An ATT Signed Write Command is produced when an application calls bt_gatt_write_without_response_cb() with sign set on an unencrypted connection. bt_smp_sign() fails whenever no local CSRK exists for the peer (-ENOENT), and whether one exists is negotiated with the peer: smp_distribute_keys() stores a local CSRK only when the peer's pairing key-distribution field requests the signing key and bonding was agreed. A peer can therefore pair without accept
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 12, 2026The Bluetooth Mesh Access layer delayable-message machinery in subsys/bluetooth/mesh/delayable_msg.c manages a static pool of CONFIG_BT_MESH_ACCESS_DELAYABLE_MSCVE-2026-19937 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.7
The Bluetooth Mesh Access layer delayable-message machinery in subsys/bluetooth/mesh/delayable_msg.c manages a static pool of CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT message contexts (default 4) threaded onto a free_ctx or busy_ctx list. release_delayable_msg_ctx() returned a context to free_ctx only when sys_slist_find_and_remove() found it on busy_ctx. The chunk-exhaustion error path in bt_mesh_delayable_msg_manage() releases a context that was already popped off free_ctx but not yet inserted on busy_ctx, so the context was appended to neither list and was permanently lost from the pool. Because bt_mesh_delayable_msg_init() runs only once from bt_mesh_init(), and node reset/suspend only drain busy_ctx, the loss survives unprovision, re-provision and suspend/resume — it is cleared only by a reboot. The error path is reached when the chunk pool (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, default 40 chunks) is short of the chunks a new delayed message needs and the oldest pending message cannot be flushed because bt_mesh_access_send() returns -EBUSY or -ENOBUFS (all segmented-TX contexts busy, or advertising/segment buffers exhausted). A peer that is provisioned into the me
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 12, 2026The Bluetooth Mesh Access-layer delayable message queue in subsys/bluetooth/mesh/delayable_msg.c shares three intrusive lists (busy_ctx, free_ctx, free_chunks) CVE-2026-19936 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 4.8
The Bluetooth Mesh Access-layer delayable message queue in subsys/bluetooth/mesh/delayable_msg.c shares three intrusive lists (busy_ctx, free_ctx, free_chunks) and one k_work_delayable between two cooperative threads with no synchronization: bt_mesh_delayable_msg_manage() runs on the Bluetooth host RX thread, while delayable_msg_handler() runs on the system workqueue. Both block while the lists are in an intermediate state — the enqueuer in bt_rand(), both in bt_mesh_access_send() — which lets the other context observe torn state. delayable_msg_handler() used the result of sys_slist_get() on busy_ctx without a NULL check, and allocate_delayable_msg_ctx() tested sys_slist_is_empty() and then assumed a separate sys_slist_get() would succeed. Because CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED default to y, every model response to a received mesh message is parked on this queue, so the enqueuer runs as a direct consequence of inbound traffic. A peer that can get access-layer messages accepted by a model (it must hold the NetKey and a bound AppKey, so a legitimate or compromised network member) controls the arrival rate, the size of the elic
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The Bluetooth LE host queues received L2CAP connection-oriented channel (CoC) data for deferred processing through a struct k_work embedded in the channel objecCVE-2026-19935 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.5
The Bluetooth LE host queues received L2CAP connection-oriented channel (CoC) data for deferred processing through a struct k_work embedded in the channel object (le_chan->rx_work, handler l2cap_rx_process()) whenever the channel uses a dynamic PSM (0x0080-0x00FF). Channel teardown in l2cap_chan_destroy() in subsys/bluetooth/host/l2cap.c cancels the retransmission-timeout work and drains the RX FIFO, but never cancels rx_work. Because that work item was submitted to the system workqueue while HCI receive processing runs on the dedicated Bluetooth RX workqueue (CONFIG_BT_RECV_WORKQ_BT, the default), a queued rx_work item can outlive the channel it points into. A remote, unauthenticated peer with an established CoC channel triggers this by sending a data K-frame immediately followed by an L2CAP Disconnect Request. The K-frame submits rx_work to the system workqueue; because both workqueue threads are cooperative and the Bluetooth RX workqueue runs at the higher priority (K_PRIO_COOP(CONFIG_BT_RX_PRIO) versus CONFIG_SYSTEM_WORKQUEUE_PRIORITY), the pending item cannot run before the following Disconnect Request is processed in le_disconn_req() -> l2cap_chan_del() -> l2cap_chan_destroy
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UCVE-2026-19740 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UPDATE_IND so that it can later be reused for the host notification when the update instant is reached (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, and the node is deliberately not recycled while marked NODE_RX_TYPE_RETAIN). The invalid-PDU arms of llcp_lp_pu_rx() and llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completed the procedure via llcp_lr_complete() / llcp_rr_complete() without first releasing that retained node, so the procedure context — the only remaining reference to the node — was freed while the node was still held out of the receive pool. A peer device on an established LE connection can drive this deterministically and without pairing or encryption. Against a peripheral it sends LL_PHY_REQ, receives LL_PHY_RSP, sends a valid LL_PHY_UPDATE_IND with an instant a few connection events in the future (so the node becomes retained), and then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ; ull_cp_rx() routes it to the active rem
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update CVE-2026-19739 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update / Connection Parameter procedure waits for its instant, so the node can later carry the host notification (llcp_rx_node_retain(), which marks it NODE_RX_TYPE_RETAIN and thereby suppresses the normal recycling in ull.c). The default: arm of llcp_rp_cu_rx() and llcp_lp_cu_rx() — the "invalid PDU, terminate the connection" path — completed the procedure without releasing that retained node. llcp_rr_check_done() then dequeued and freed the procedure context with ctx->node_ref.rx still pointing at the retained node, dropping the last reference to it. A peer device in radio range can reach this without pairing, bonding, or encryption. Against a peripheral, the peer sends a well-formed LL_CONNECTION_UPDATE_IND with an instant a few connection events in the future (the node is retained and the procedure enters RP_CU_STATE_WAIT_INSTANT), then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ. ull_cp_rx() routes that PDU into the active remote Connection Update procedure, which takes the invalid-PDU
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation retains an RX node (ctx->node_ref.rx, marked NOCVE-2026-19738 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
The Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation retains an RX node (ctx->node_ref.rx, marked NODE_RX_TYPE_RETAIN) so it can later be reused as the host notification — on the peripheral while awaiting the Host's reply to an LL_CIS_REQ, and on the central for the whole duration of a locally initiated CIS Create. In subsys/bluetooth/controller/ll_sw/ull_llcp_cc.c, the "invalid PDU received" paths of llcp_rp_cc_rx() and llcp_lp_cc_rx() terminated the connection and completed the procedure without releasing that retained node, breaking the invariant checked in llcp_lr_check_done() and llcp_rr_check_done() and orphaning the node's memory. A peer device within radio range can reach this with a single extra LL Control PDU on an unauthenticated, unencrypted ACL link. Against a peripheral, the attacker sends a valid LL_CIS_REQ and then, before the Host replies, any unrelated LL Control PDU (for example LL_VERSION_IND), which ull_cp_rx() routes into the active remote procedure. Against a central performing a CIS Create, a malicious peripheral answers with LL_UNKNOWN_RSP for CIS_REQ, which is dispatched into the active local pro
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH.CVE-2026-19737 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.5
i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH. The I2S_DIR_RX and I2S_DIR_TX branches read dev_cfg->rx.data->configured / dev_cfg->tx.data->configured without first checking the stream pointers. The device instantiation macro I2S_ESP32_STREAM_INIT() sets both .conf and .data to NULL for a direction the devicetree does not describe, so on an instance that wires only one direction — the normal shape for audio output or a worldsemi,ws2812-i2s LED strip — the other direction dereferences a NULL pointer instead of returning an error. i2s_trigger() is a Zephyr syscall, and z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only the device object and the presence of the trigger API pointer; the dir argument is passed to the driver unvalidated. On a build with CONFIG_USERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2s_trigger() call naming the unwired direction and cause a load from address 0 in kernel mode. Among the Espressif parts that carry this driver, userspace is available in-tree only on RISC-V SoCs with CONFIG_RISCV_PMP, and v4.4.0 is the first release where that
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData().CVE-2026-19736 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNG_SW_HEALTH_TESTS variant, which always copies whole 32-bit words and draws entropy rounded up to a multiple of 128 bytes. Its "caller buffer is full" guard tests dataSize == 0, so a request whose length is not a multiple of four makes dataSize underflow past zero and the SDK keeps writing into the caller's buffer for the entire extraction: a 1-byte request results in 128 bytes written, and any non-word-multiple length overflows by up to 127 bytes. entropy_get_entropy() is a syscall, and its verifier in drivers/entropy/entropy_handlers.c validates only the requested length via K_SYSCALL_MEMORY_WRITE(). With CONFIG_USERSPACE enabled, an unprivileged user-mode thread that has merely been granted the entropy device can therefore choose both the destination address and a length such as 1, and cause the kernel to write up to 127 bytes beyond the region it proved it owns. On these Cortex-M33 targets there is no MMU, so user partitions and kernel data share one SRAM and the ove
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The RFC 6528 initial-sequence-number implementation in subsys/net/ip/tcp.c derived every TCP ISN from SHA-256(unique_key || four-tuple) plus a uptime-derived ofCVE-2026-19735 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 4.8
The RFC 6528 initial-sequence-number implementation in subsys/net/ip/tcp.c derived every TCP ISN from SHA-256(unique_key || four-tuple) plus a uptime-derived offset, where unique_key is a 128-bit secret filled once by sys_csrand_get(). The return value of that call was discarded and the once guard was latched to true even when the call failed. Because sys_csrand_get() leaves the destination buffer untouched on failure (it deliberately propagates the entropy-driver error rather than filling the buffer), a single failed call left unique_key as its all-zero BSS content for the remainder of the boot, with no retry, no log message and no fallback. A failure of the cryptographic random source is required to reach the weak state — for example -ENODEV/-EIO from the entropy driver in subsys/random/random_entropy_device.c (the in-tree comment notes that the hardware RNG "might still be gathering entropy during early boot situations"), or psa_generate_random() failing in subsys/random/random_psa.c when PSA crypto is not initialised or is backed by a Bluetooth-HCI entropy device that is not yet up. The first TCP connection is what triggers key generation, so a remote peer that reaches a liste
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The user-mode syscall verifiers z_vrfy_fuel_gauge_get_props() and z_vrfy_fuel_gauge_set_props() in drivers/fuel_gauge/fuel_gauge_syscall_handlers.c declared twoCVE-2026-19669 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The user-mode syscall verifiers z_vrfy_fuel_gauge_get_props() and z_vrfy_fuel_gauge_set_props() in drivers/fuel_gauge/fuel_gauge_syscall_handlers.c declared two variable-length arrays, union fuel_gauge_prop_val k_vals[len] and fuel_gauge_prop_t k_props[len], sized directly by the caller-supplied len argument. len is an unvalidated size_t taken straight from the syscall ABI, and the VLAs were allocated before any check at all — including before the K_SYSCALL_DRIVER_FUEL_GAUGE() object-permission check. The subsequent k_usermode_from_copy() calls validated only that the user source buffer was readable; the kernel destination was never bounds-checked, since it was sized by the same attacker-chosen len. Any thread running in user mode with CONFIG_USERSPACE enabled can invoke fuel_gauge_get_props() or fuel_gauge_set_props() with a large len. This first displaces the supervisor stack pointer by an arbitrary attacker-chosen amount — Zephyr does not build with stack-clash probing, so the displacement itself does not fault, and the nested calls made by the verifier then write frames below the privileged stack. If the caller has been granted access to a fuel-gauge device object, the memcpy
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026net_route_ipv6_packet() in subsys/net/ip/route_ipv6.c resolved the nexthop's link-layer address with net_nbr_get_lladdr(nbr->idx) without first checking whetherCVE-2026-19577 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.1
net_route_ipv6_packet() in subsys/net/ip/route_ipv6.c resolved the nexthop's link-layer address with net_nbr_get_lladdr(nbr->idx) without first checking whether the neighbor cache entry actually had a linked link-layer address. An unresolved neighbor carries idx == NET_NBR_LLADDR_UNKNOWN (0xff), and net_nbr_get_lladdr() in subsys/net/ip/nbr.c performs no runtime bounds check beyond a NET_ASSERT, returning &net_neighbor_lladdr[255] — roughly 2.5 KB past the end of an array whose default size is CONFIG_NET_IPV6_MAX_NEIGHBORS (8). Because the returned pointer is never NULL, the following lladdr == NULL guard does not catch it. The function is reached from ipv6_route_packet() in subsys/net/ip/ipv6.c for every received unicast IPv6 packet whose destination is not a local address on the receiving interface; CONFIG_NET_IPV6_ROUTE is enabled by default whenever the IPv6 neighbor cache is, so no router or forwarding configuration is needed. net_route_ipv6_get_info() returns the packet's destination itself as the nexthop when a neighbor cache entry for it exists, and the cache lookup does not skip INCOMPLETE entries. An unauthenticated attacker on the same link can therefore force the unres
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller's status register and masks it with GT911_TOUCH_POICVE-2026-19576 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.8
The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller's status register and masks it with GT911_TOUCH_POINTS_MSK (0x0F), yielding a value of 0..15. In gt911_process() that value is used directly as the loop bound for filling point_reg[], a stack array sized to CONFIG_INPUT_GT911_MAX_TOUCH_POINTS, whose Kconfig range is 1..5 with a default of 1. No other check constrains the count; the driver relied only on a comment asserting that the controller had been programmed at init to report no more points than configured. Each loop iteration issues an I2C read of eight bytes straight into point_reg[i], so a controller that reports more points than the array holds causes up to 112 bytes of peer-supplied data to be written past the end of the array, over the stack frame of gt911_process() in the system workqueue thread. Two further loops then read out of bounds from the same array. Triggering it requires control of, or the ability to substitute, the I2C touch controller — plausible on the many supported boards where the GT9xx panel is a pluggable display module or shield rather than an on-PCB part; a spoofed device need only answer the
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 11, 2026The zbus proxy agent IPC backend in subsys/zbus/proxy_agent/zbus_proxy_agent_ipc.c logged the channel name of a rejected inter-domain frame with a plain %s convCVE-2026-18418 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgLow 3.4
The zbus proxy agent IPC backend in subsys/zbus/proxy_agent/zbus_proxy_agent_ipc.c logged the channel name of a rejected inter-domain frame with a plain %s conversion. The frame type struct zbus_proxy_msg carries a fixed-size channel_name[] array as its last member, and nothing in the transport guarantees the array is NUL-terminated. The only code that verifies termination is zbus_proxy_agent_receive_cb() in subsys/zbus/proxy_agent/zbus_proxy_agent.c, which rejects the frame in precisely those cases — so the warning printed a non-terminated buffer exactly on the error paths where the name had been found invalid (or, for an invalid message_size, had not been inspected at all). Any peer domain able to place a frame of sizeof(struct zbus_proxy_msg) bytes on the bound ipc_service endpoint can trigger it, by sending a frame with an out-of-range message_size or with channel_name[] containing no NUL byte. Reaching the code requires CONFIG_ZBUS_PROXY_AGENT_IPC and logging built at warning level or above (the default), and requires control over the firmware of the peer domain — typically a second core on the same SoC. The resulting strlen() inside the log packager walks past the end of th
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 9, 2026The user-mode verification handler for the device_deinit() system call, z_vrfy_device_deinit() in kernel/device.c, validated its dev argument with K_SYSCALL_OBJCVE-2026-19575 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7.8
The user-mode verification handler for the device_deinit() system call, z_vrfy_device_deinit() in kernel/device.c, validated its dev argument with K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). k_object_validate() short-circuits its type comparison when the requested type is K_OBJ_ANY, so the check reduced to "this pointer is the base address of some kernel object the calling thread has been granted" — the object's actual type was never compared, and K_SYSCALL_OBJ_INIT also skips the initialization-state check. The sibling handlers z_vrfy_device_init() and z_vrfy_device_is_ready() already used K_OBJ_DRIVER_ANY and were unaffected. A thread running in user mode can therefore pass any kernel object it holds permission on — most usefully a thread stack object obtained from the k_thread_stack_alloc() syscall or a statically defined K_THREAD_STACK it was granted in order to spawn a child user thread — whose backing memory is writable from user mode. z_impl_device_deinit() then interprets those attacker-written bytes as a struct device: it dereferences the state pointer read out of the object, calls the function pointer read out of ops.deinit, and on success writes through state again. The result
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 9, 2026The ARM64 MMU back-end allocated address space identifiers (ASIDs) for memory domains with a bare round-robin counter in arch_mem_domain_init() (arch/arm64/coreCVE-2026-19574 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgHigh 7
The ARM64 MMU back-end allocated address space identifiers (ASIDs) for memory domains with a bare round-robin counter in arch_mem_domain_init() (arch/arm64/core/mmu.c). VM_ASID_BITS is 8, so only 255 ASIDs exist; once the counter wrapped, arch_mem_domain_init() could hand an ASID to a new domain while a still-live domain held the same one. Domain-private mappings are installed non-global (MT_NG), so the ASID is the only tag separating one domain's cached translations from another's in the TLB. The context-switch path in z_arm64_swap_ptables() only flushes the TLB when the outgoing and incoming domains carry the same ASID, which does not cover a duplicate reached through a third domain: for domains A and C sharing an ASID and an unrelated domain B, the schedule A -> B -> C never takes the flush branch, so the ASID-tagged entries A populated remain resident while C runs. Under SMP two live domains sharing an ASID can additionally be resident on two CPUs at once, which the architecture does not allow for distinct translation-table sets. Triggering the wrap requires a CONFIG_USERSPACE application on ARM64 that creates more than 255 memory domains over its lifetime; k_mem_domain_init(
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 9, 2026The ITE IT8xxx2 SHI host-command backend (subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c) copied the 8-byte host-command request header from theCVE-2026-19571 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.7
The ITE IT8xxx2 SHI host-command backend (subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c) copied the 8-byte host-command request header from the SPI Rx FIFO directly into the shared receive buffer data->in_msg and only afterwards checked the protocol version and the derived packet length. The interrupt handler also accepted a chip-select assertion and an Rx-valid-length (RVLI) interrupt in any driver state other than SHI_STATE_DISABLED, so a new header could be parsed while the host-command thread was still processing the previous request out of the very same buffer. The host processor is the SPI controller and drives both chip select and the clock. After sending a well-formed request it can immediately de-assert chip select — which returns the driver to the ready state and re-enables the FIFO — and start a second transaction carrying a header with data_len = 0xFFFF. Those eight bytes are written into in_msg before the oversized length is rejected, so they land in a buffer whose contents verify_rx() in subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c has already validated. If this lands in the window before the host-command thread executes args.input_buf_size = rx_hea
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.
Weekly security brief
The flaws that hit local websites, every Friday.
One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.
Tell us what you're building.
A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.
Not ready to talk yet? Run the free website check and see what Google sees.