Threats affecting pkg:github/Zephyr

CVE-2026-81039 is a denial-of-service vulnerability in the Zephyr Bluetooth host stack affecting versions >=2.3.0 <4.3.2 and >=4.4.0 <4.5.0. It arises from incorrect reservation handling when multiple connectable extended advertising sets run on the same identity. An adjacent attacker can exhaust connection reservation slots by triggering mis-attribution of connection reservations, causing the device to fail accepting new connections until reboot or Bluetooth disable. The issue impacts availability only, with no memory corruption or data leakage.

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 through LE Extended Advertising Report events, which the controller fragments only to CONFIG_BT_BUF_EVT_RX_SIZE. In the stock configuration the overflow is already reached without any radio traffic: the mandatory Read Supported Commands command-complete event is 70 bytes and overruns the 64-byte slot by six bytes on every host initialization. Because net_buf_add_mem() validates tailroom only through an assertion unless CONFIG_NET_BUF_HARDENING is enabled, builds with CONFIG_ASSERT=n — the usual production setting — silently corrupt memory adjacent to the USB buffer pool with attacker-chosen contents, which on a target without memory protection between subsystems can lead to arbitrary code execution. Builds with assertions enabled fail the assertion instead and panic, giving a remotely triggerable denial of service. The fix introduces a separate bt_hci_tx_pool sized to MAX(BT_BUF_ACL_RX_SIZE, BT_BUF_EVT_RX_SIZE) for the controller-to-host direction while leaving the host-to-device pool at the endpoint packet size, which is already bounds-checked during reassembly.

CVE-2026-79981 is a medium severity vulnerability in the Zephyr project's DNS stub resolver affecting versions from 1.8.0 up to but not including 4.5.0. The resolver uses a fixed source UDP port per server for DNS queries, violating RFC 5452's requirement that both source port and transaction ID vary. This allows an off-path attacker with UDP reachability to flood forged DNS responses and potentially cause the application to resolve attacker-chosen addresses. The vulnerability is mitigated by a fix in version 4.5.0 that randomizes the source port per query, increasing the guessing space and reducing attack feasibility.

CVE-2026-79980 is a medium-severity vulnerability in the DHCPv4 client of the Zephyr project. The client used a predictable transaction identifier that was incremented or reused rather than randomly generated per transaction as required by RFC 2131. This flaw allows an attacker who learns or predicts the transaction ID to forge DHCP replies that can redirect network traffic by altering gateway and DNS settings. The issue affects Zephyr versions from 1.7.0 up to but not including 4.5.0. A fix is available in version 4.5.0, which ensures fresh random transaction IDs are generated for each DHCP transaction phase.

CVE-2026-79979 is a use-after-free vulnerability in the Zephyr project affecting the arm64 MMU backend. The flaw arises because the TLB invalidation only targets ASID 0 and global entries, allowing cached translations for other ASIDs to survive eviction. This enables unprivileged user threads to access stale memory mappings, potentially leading to information disclosure, memory corruption, and full system compromise. The issue affects Zephyr versions from 4.3.0 up to but not including 4.5.0 and is fixed in version 4.5.0.

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, 8, 32, 64, 4) used by sensor stream <dev> on fifo_wm incl, or the 16-byte-block streaming example in the documentation — takes this path whenever the pool is fragmented or the consuming thread falls behind. The out-of-bounds writes are performed by the I2C/SPI RTIO backend (DMA on many SoCs) into the shared RTIO block pool, corrupting neighbouring live buffers or, for a pool smaller than one batch, memory beyond the pool itself. The written bytes are accelerometer samples and the destination follows the allocation, so there is no controllable corruption primitive: the realistic impact is silent corruption of other RTIO consumers' data or a crash. Reaching it requires a board with an interrupt-wired ADXL345 built with CONFIG_ADXL345_STREAM, plus buffer-pool starvation, which a co-resident local workload can induce but which also occurs spontaneously under load; there is no network, USB or radio path to this code.

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 datagram carrying the transport-data type, zeroed reserved bytes and an arbitrary receiver index is sufficient. The vulnerable branch runs whenever the peer has neither a valid handshake nor a current keypair — the state at boot and after a session expires. A single spoofed datagram redirects peer->endpoint to an address of the attacker's choosing, and all subsequent handshake initiations, keepalives and encrypted data packets are sent there. The legitimate peer never receives the initiations and so never re-authenticates, and nothing resets the endpoint afterwards, leaving the tunnel persistently unusable on devices whose peer does not initiate handshakes itself. The attacker can also relay the redirected initiations to the real peer to place itself in the path of the tunnel, observing ciphertext and traffic metadata and selectively dropping packets. WireGuard's end-to-end cryptography still prevents decryption or forgery of tunnel content, so the impact is loss of availability plus limited confidentiality, not key compromise. The fix removes the endpoint learning from this path entirely: the stale-session recovery is kept, but the handshake is sent only to an endpoint learnt from an authenticated message, falling back to the configured cfg_endpoint, and the message is dropped when neither is known. CONFIG_WIREGUARD is marked experimental and is not enabled by default.

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 erase) can run any stock Thread commissioner registered with J01NME, complete the handshake, and hand the device an attacker-controlled operational dataset. The device then joins and enables Thread on the attacker's mesh. The attacker becomes its router, seeing, dropping, injecting and spoofing all of the device's IPv6 traffic and impersonating the peers the application expects, while the device is cut off from the network it was meant to join and stays mis-provisioned until it is reset. Only application-layer security with independently provisioned credentials survives. Exposure is limited to builds that enable joiner autostart and leave the PSKd unset; the option is not enabled by default and no in-tree sample uses the vulnerable combination. The fix removes the default from CONFIG_OPENTHREAD_JOINER_PSKD and adds a BUILD_ASSERT() in modules/openthread/openthread.c, active only under CONFIG_OPENTHREAD_JOINER_AUTOSTART, that fails the build unless a 6-to-32-character PSKd is configured. Products should provision a per-device PSKd from factory data and call otJoinerStart() from the application rather than relying on a credential compiled identically into every unit.

CVE-2026-19947 is a vulnerability in the Zephyr project affecting the device multiplexer pseudo-driver when user mode and devmux features are enabled. It allows unprivileged user-mode threads to bypass device permission checks and change the downstream device selection of the multiplexer. This can lead to suppression or redirection of console, log, and shell output. The issue is due to missing kernel-object validation in user-mode syscall verifiers and the absence of proper driver API registration, which prevents permission enforcement. The vulnerability is fixed in Zephyr version 4.5.0.

CVE-2026-79976 is a memory-safety vulnerability in the Zephyr project's MCTP-over-I2C+GPIO target binding. It arises because certain state variables are not cleared on I2C STOP conditions, leading to use-after-free dereferences of packet buffers. This can cause fatal exceptions and device resets (denial of service) on targets that trap null pointer accesses. The flaw affects builds with the experimental CONFIG_MCTP subsystem enabled and CONFIG_MCTP_I2C_GPIO_TARGET set to yes. The issue is fixed in Zephyr versions 4.3.2 and 4.5.0.

CVE-2026-78119 is a vulnerability in the Zephyr project's Nuvoton NPCX eSPI driver affecting versions 3.6.0 up to but not including 4.5.0. The flaw involves improper bounds checking when parsing Target-Attached-Flash (TAF) requests, allowing out-of-bounds writes and reads in the eSPI controller memory. This can lead to controller crashes, hangs, or corruption of driver state that controls flash protection. The vulnerability requires host firmware or bus-level control to exploit and is not reachable by ordinary host software. A fix is available in Zephyr version 4.5.0 that adds proper bounds checking and rejects invalid requests. No in-tree board enables the vulnerable feature by default.

CVE-2026-78118 is a race condition vulnerability in the Zephyr kernel's wait queue handling on SMP (multi-CPU) systems. The kernel helper z_waitq_head() reads the head of a thread wait queue without holding the necessary scheduler spinlock, leading to potential use-after-free and out-of-bounds writes. This can cause scheduler state corruption or kernel crashes. Exploitation requires local code execution, multiple CPUs, and precise timing, making crashes more common than controlled corruption. The issue is fixed in Zephyr version 4.5.0.

CVE-2026-78117 is a race condition vulnerability in the Infineon PSOC 6 BLESS HCI driver within the Zephyr project. The driver uses a shared static variable for outgoing HCI packet descriptors, which is not fully protected by the semaphore, allowing concurrent senders to interleave and cause data leakage or packet duplication. This can disclose adjacent RAM contents to a connected Bluetooth peer and disrupt the link. The issue is fixed by making the descriptor a local variable, eliminating shared state.

CVE-2026-18748 is a low-severity vulnerability in the Zephyr Bluetooth Classic A2DP host stack. It involves an inconsistent handling of the codec Information Element (IE) length field, where the length can exceed the actual stored bytes, leading to out-of-bounds reads of adjacent memory. This can cause disclosure of adjacent RAM contents to a paired Bluetooth peer. The flaw requires specific configuration and pairing conditions and does not allow out-of-bounds writes or code execution.

CVE-2026-78116 is a use-after-free vulnerability in the Broadcom AFBR-S50 time-of-flight sensor driver in Zephyr. The driver double-completes an RTIO submission when sensor data evaluation fails, leading to memory corruption and loss of availability. This occurs because an error handling path finalizes the same request twice without returning, causing freed memory to be reused improperly. The issue can be triggered by sensor conditions such as harsh ambient light or SPI transfer errors, without requiring software access or physical contact. Only builds enabling this driver are affected.

CVE-2026-19676 is a memory safety vulnerability in the Zephyr project's PECI driver system calls. It allows a user-mode thread with PECI device access to perform arbitrary kernel memory reads and writes due to insufficient validation of buffer pointers and lengths. This can lead to a full user-to-kernel privilege escalation, including arbitrary code execution at supervisor level. The flaw requires user-mode access to PECI devices and specific PECI drivers enabled. The issue is fixed in Zephyr versions 4.3.2 and 4.5.0.

CVE-2026-77684 is a denial-of-service vulnerability in the Zephyr Bluetooth Classic Hands-Free Profile (HFP) HF role. The flaw occurs because AT command buffers queued for transmission are not released when the RFCOMM data link connection goes down, leading to exhaustion of a fixed buffer pool. This causes permanent failure in sending HFP commands and can park the Bluetooth RX thread, halting all HCI event processing until reboot. The issue affects Zephyr versions from 4.2.0 up to but not including 4.5.0 and is fixed in version 4.5.0.

CVE-2026-19595 is a memory-safety vulnerability in the Zephyr RTOS user-mode syscall verifier for the rtio_cqe_get_mempool_buffer() function. The syscall incorrectly validates output pointer parameters with read permissions instead of write permissions, allowing an unprivileged user-mode thread with access to an RTIO context to cause kernel-mode stores to memory regions that should be read-only. This can lead to either bypassing memory domain write protections or triggering a kernel fault that halts or reboots the device, causing denial of service. The issue is fixed by enforcing write permission checks on the output pointers before the syscall implementation runs.

CVE-2026-76788 is a high-severity vulnerability in the Zephyr project's OSDP Control Panel reply parser. It involves a lack of proper bounds checking on payload lengths for certain reply types, allowing an attacker with access to the RS-485 bus to cause a buffer overflow. This can lead to crashes or potential control-flow hijacking in the OSDP receive thread. The issue affects Zephyr versions from 3.3.0 up to but not including 4.3.2, and from 4.4.0 up to but not including 4.5.0. The vulnerability is fixed in versions 4.3.2 and 4.5.0.

CVE-2026-76787 is a memory-safety vulnerability in the Zephyr project's UpdateHub firmware-over-the-air client. It arises from improper handling of JSON metadata in CoAP probe responses, where a missing 'sha256sum' field leads to a NULL pointer dereference. This causes a read at address zero, resulting in a denial of service by crashing or halting the system depending on the hardware configuration. The vulnerability can be triggered remotely without authentication when DTLS is disabled, allowing an attacker to cause repeated system crashes. The issue is fixed in Zephyr versions 4.3.2 and 4.5.0.