Threats affecting pkg:github/zephyr

CVE-2026-82962 is a memory-safety vulnerability in the Zephyr project affecting Ethernet packet handling. It occurs when the ethernet_fill_header() function prepends an Ethernet header in place without verifying sufficient headroom in the packet buffer, leading to out-of-bounds memory writes. This flaw can be triggered by forwarding packets from other network layers or interfaces, causing memory corruption that may result in crashes or packet corruption. The vulnerability affects Zephyr versions from 4.1.0 through 4.4.2. The CVSS score is 6.5, indicating medium severity.

CVE-2026-82961 is a vulnerability in the Zephyr project's GPIO syscall handlers where user-mode callers could supply an unvalidated pin argument. This lack of validation allows out-of-bounds memory access in kernel space, potentially leading to arbitrary code execution or system crashes. The flaw affects Zephyr versions from 2.2.0 through 4.4.2 and requires user-mode access to a GPIO device object. The vulnerability is mitigated by validating the pin argument against the controller's supported pins and range checks.

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 example a protocol peer whose connection causes a session key to be installed — can influence which key is resident when a victim operation runs. The impact is a cryptographic failure rather than memory corruption: data the application believed it was protecting under one key is encrypted or decrypted under another. Where the resident key is one the attacker knows or supplied, the affected plaintext becomes recoverable by that attacker, and the operation's direction (encrypt versus decrypt) can likewise be inverted. Exposure requires an application that holds two or more concurrent sessions with different keys against this driver; no in-tree Zephyr subsystem does so today (the 802.15.4 security layer, which does open two sessions, uses CCM mode, which this driver rejects), so the risk falls on application code that uses the documented multi-session API. The fix removes all hardware access from aes_begin_session() and reprograms the key and direction at the top of every operation, inside aes_lock, so the chip-global registers can no longer be observed stale by another session.

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's SDP record requires no pairing, and the peer can also trigger the failure by dropping the ACL or racing an RFCOMM DLC on the same DLCI at the right moment. When the SDP client next advances its request list, sdp_client_discover() dereferences the zeroed parameters — net_buf_alloc(param->pool, …) with a NULL pool and param->uuid->type — and the result-notification paths call through the NULL params->func. Zeroing a linked node also truncates the request list behind a stale tail pointer, and re-arming the freed AG slot re-appends the same node and can produce a self-looping list that hangs the Bluetooth RX thread. The impact is a crash or hang of the Bluetooth stack; the written value is a constant zero at a fixed static address, so no attacker-controlled write is available. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_AG that use the Audio Gateway role are affected.

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, so a remote device advertising an HFP AG record with an RFCOMM channel outside 1-30 makes bt_rfcomm_dlc_connect() return -EINVAL and drives the local device into the wipe. The same branch is reached without any application misuse when the remote peer controls connection timing, for example when the RFCOMM session is in BT_RFCOMM_STATE_DISCONNECTING or the ACL is dropped between object creation and the RFCOMM call. Once the object has been wiped, the Bluetooth host continues to use it: sdp_client_alloc_buf() dereferences session->param->pool, which is now NULL, and the SDP receive paths call session->param->func() through a null function pointer, neither of which is NULL-checked. Because the wipe also clears hf->acl, the pool slot is considered free and a retry or an incoming HFP connection re-appends the same still-linked list node, turning session->reqs into a self-referential list that the host's list walkers never leave. The result is a fault or an unrecoverable hang in the Bluetooth host thread; the stray indirect call is through an all-zero pointer whose target the attacker does not control, so the practical impact is denial of service. The fix keeps the object allocated and marks it with a new BT_HFP_HF_FLAG_RELEASING flag, letting bt_hfp_hf_discover_cb() release it once the discovery completes instead of destroying it under the SDP client. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled are affected.

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() silently falls back to k_cycle_get_32() samples when the entropy driver fails, and returns no error, so the key could be derived from the cycle counter without the caller noticing. With the key known, stable IIDs become directly computable for any prefix (the remaining HMAC inputs — prefix, interface index, interface name, DAD counter — are guessable), and temporary IIDs become linkable after a cheap search over the mixed-in k_uptime_get_32() value. This defeats the properties both features exist to provide: an attacker can track a device across networks and prefixes, and can predict its address inside a /64 without scanning, removing the usual barrier to directly targeting the host. There is no memory-safety, integrity, or availability impact. The fix generates the key with sys_csrand_get() and aborts IID generation with -EIO when no cryptographic randomness is available, instead of silently deriving addresses from a predictable key. Both CONFIG_NET_IPV6_IID_STABLE and CONFIG_NET_IPV6_PE are experimental and disabled by default; builds using CONFIG_TEST_RANDOM_GENERATOR remain predictable by design, as sys_csrand_get() is deliberately routed back to the test generator there.

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_command_decode() accepts the Calculate Checksum op code unconditionally (it is not guarded by CONFIG_BT_OTS_OACP_CHECKSUM_SUPPORT), builds without checksum support are reachable too: they answer BT_GATT_OTS_OACP_RES_OPCODE_NOT_SUP and take the same bad path. On builds with CONFIG_ASSERT enabled, the zero-length pull trips the assertion inside net_buf_simple_pull_mem() and panics the device, giving a remotely triggered denial of service. On builds with assertions disabled there is no check: the pull returns the untouched stack array and four bytes of uninitialized stack memory are copied into the indication and transmitted to the peer, repeatable on every request. The disclosure is bounded to four bytes per request and the write stays inside the seven-byte res indication buffer, so there is no memory corruption; the impact is uninitialized-memory disclosure plus an availability loss in assertion-enabled configurations.

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 initiator address is chosen freely by the remote device and is not authenticated at link establishment, so no bonding, pairing or prior relationship is required to trigger the mis-attribution. The undirected set's own reservation is then stranded: its BT_ADV_ENABLED flag has already been cleared, and le_adv_stop_free_conn() — the only path that returns a reservation to the pool — is reached only for sets that are still enabled, so bt_le_ext_adv_stop() returns early and the object is never released. Each occurrence permanently consumes one CONFIG_BT_MAX_CONN slot until bt_disable() or reboot. In application patterns that restart the directed advertising set after each disconnect, an attacker can repeat the sequence until the pool is exhausted, after which connectable advertising fails with -ENOMEM and the device can no longer accept connections. As a side effect the directed set keeps advertising without a reservation, so a genuine connection on it is dropped by bt_hci_disconnect(). The impact is availability only; no memory corruption or information disclosure results, and configurations with a single advertising set are unaffected.

CVE-2026-79982 is a high-severity vulnerability in the Zephyr project's Bluetooth HCI USB transport class. It involves a buffer overflow caused by copying oversized HCI packets into a fixed-size USB transfer buffer without proper length checks. This can lead to memory corruption or denial of service. The flaw affects Zephyr versions from 3.3.0 through 4.4.2. An attacker within Bluetooth range can exploit this by sending oversized packets, potentially causing arbitrary code execution on systems without memory protection or triggering a panic on others.

CVE-2026-79981 is a medium severity vulnerability in the Zephyr project's DNS stub resolver. The resolver binds a single UDP socket with a fixed ephemeral source port for all DNS queries to a configured server, violating RFC 5452's requirement that both source port and transaction ID vary. This allows an off-path attacker with UDP reachability to the device to guess the source port easily and flood forged DNS responses, potentially causing the application to resolve attacker-chosen addresses. The vulnerability affects Zephyr versions from 1.8.0 up to but not including 4.5.0. A patch is available that randomizes the source port per query, increasing the guessing space and mitigating the risk.

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 randomized per transaction as required by RFC 2131. This allowed an attacker who observed one identifier to predict future identifiers and forge DHCP replies. Such forged replies could redirect network traffic by changing the device's default gateway and DNS resolvers or disrupt network configuration by sending forged DHCPACK or DHCPNAK messages. A patch is available that ensures a fresh random transaction identifier is generated for each DHCP transaction phase.

CVE-2026-79979 is a use-after-free vulnerability in the Zephyr project affecting arm64 builds with CONFIG_USERSPACE and CONFIG_DEMAND_PAGING enabled. The issue arises from improper TLB invalidation that only targets ASID 0, allowing stale translations for other ASIDs to persist. This flaw enables unprivileged user threads to access and modify kernel or other domain memory, breaking memory isolation and potentially leading to full system compromise. The vulnerability affects Zephyr versions from 4.3.0 up to but not including 4.5.0. A fix has been implemented to correct the TLB invalidation to cover all ASIDs and preserve proper memory domain permissions.

CVE-2026-79978 is a low-severity vulnerability in the Zephyr RTOS affecting the ADXL345 accelerometer driver. The issue arises from out-of-bounds writes during FIFO data processing when the allocated buffer is smaller than a full batch. This can cause silent data corruption or crashes due to memory corruption in the RTIO block pool. Exploitation requires specific hardware configuration and buffer pool starvation conditions.

CVE-2026-79977 is a vulnerability in the WireGuard VPN implementation within Zephyr (subsys/net/lib/wireguard/wg.c) that allows an attacker to spoof the peer endpoint address without authentication. This occurs because the code updates the peer endpoint from unauthenticated messages when the receiver index does not match any session. The flaw enables an attacker to redirect traffic to an arbitrary address, causing denial of service or limited traffic interception without decrypting or forging tunnel content. The vulnerability affects Zephyr versions from 4.4.0 through 4.4.2. A fix removes unauthenticated endpoint updates and restricts handshake initiation to authenticated endpoints or configured endpoints. WireGuard in Zephyr is experimental and not enabled by default.

Zephyr's OpenThread integration used a default, publicly known Joining Device Credential (PSKd) "J01NME" when the joiner autostart feature was enabled but the PSKd was not overridden. This allowed an attacker within radio range to authenticate as a commissioner and provision the device with a malicious operational dataset, effectively taking control of the device's Thread network connection. The vulnerability affects Zephyr versions from 1.14.0 up to but not including 4.5.0. A fix was implemented to remove the default PSKd and enforce build-time checks requiring a unique PSKd when joiner autostart is enabled.

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. The flaw occurs because certain state variables are not cleared upon an I2C STOP condition, allowing a controller on the bus to cause a NULL pointer dereference. This leads to a fatal exception and device reset or halt, resulting in a denial of service. The vulnerability affects only builds with the experimental CONFIG_MCTP subsystem enabled and CONFIG_MCTP_I2C_GPIO_TARGET set to yes. No confidentiality or integrity breach occurs, and no attacker-controlled data is written. A fix is implemented by resetting the relevant state variables at every STOP condition.

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 of the Zephyr project. The driver uses a shared static variable to store outgoing HCI packet descriptors without proper synchronization, allowing concurrent senders to cause data races. This can lead to disclosure of adjacent RAM contents to a connected Bluetooth peer and disruption of the Bluetooth link. The vulnerability affects Zephyr versions from 3.4.0 through 4.4.2. The issue is rated medium severity with a CVSS score of 4.2.