Filtered by vendor Zephyrproject
Subscribe
Total
194 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-1675 | 1 Zephyrproject | 1 Zephyr | 2026-10-13 | N/A | 8.2 HIGH |
| The function dns_copy_qname in dns_pack.c performs performs a memcpy operation with an untrusted field and does not check if the source buffer is large enough to contain the copied data. | |||||
| CVE-2025-1674 | 1 Zephyrproject | 1 Zephyr | 2026-10-13 | N/A | 8.2 HIGH |
| A lack of input validation allows for out of bounds reads caused by malicious or malformed packets. | |||||
| CVE-2025-1673 | 1 Zephyrproject | 1 Zephyr | 2026-10-13 | N/A | 8.2 HIGH |
| A malicious or malformed DNS packet without a payload can cause an out-of-bounds read, resulting in a crash (denial of service) or an incorrect computation. | |||||
| CVE-2025-10458 | 1 Zephyrproject | 1 Zephyr | 2026-10-13 | N/A | 7.6 HIGH |
| Parameters are not validated or sanitized, and are later used in various internal operations. | |||||
| CVE-2025-10457 | 1 Zephyrproject | 1 Zephyr | 2026-10-13 | N/A | 4.3 MEDIUM |
| The function responsible for handling BLE connection responses does not verify whether a response is expected—that is, whether the device has initiated a connection request. Instead, it relies solely on identifier matching. | |||||
| CVE-2025-10456 | 1 Zephyrproject | 1 Zephyr | 2026-10-13 | N/A | 7.1 HIGH |
| A vulnerability was identified in the handling of Bluetooth Low Energy (BLE) fixed channels (such as SMP or ATT). Specifically, an attacker could exploit a flaw that causes the BLE target (i.e., the device under attack) to attempt to disconnect a fixed channel, which is not allowed per the Bluetooth specification. This leads to undefined behavior, including potential assertion failures, crashes, or memory corruption, depending on the BLE stack implementation. | |||||
| CVE-2026-13479 | 1 Zephyrproject | 1 Zephyr | 2026-08-31 | N/A | 3.1 LOW |
| The LoRaWAN application-layer clock-synchronization service parses downlinks in clock_sync_package_callback() (subsys/lorawan/services/clock_sync.c). Its command loop only guarantees that the one-byte command id is in bounds; for the CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) command the handler then reads a 4-byte time correction via sys_get_le32() plus a 1-byte token without checking that 5 bytes remain in the receive buffer (len - rx_pos). A short or crafted AppTimeAns therefore reads up to 5 bytes past the end of the decrypted payload. The payload (rx_buf/len) is the decrypted application frame delivered to the registered downlink callback (mcps_indication->Buffer/BufferSize). Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN's MAC integrity check and FRMPayload decryption, so the practical attacker is a malicious or compromised network/application server (the designated sender of AppTimeAns) or a party holding the session keys, rather than an arbitrary radio listener. The over-read is bounded: the backing store is a fixed 255-byte static buffer, so the few stray bytes do not fault, and the read values (time_correction, token) are used only internally and never transmitted, so there is no disclosure to the attacker and no crash. The sole effect is that a stale token matching ctx.req_token can apply a garbage time_correction to the device's own clock offset (ctx.time_offset), a minor integrity impact confined to the victim's time estimate. The fix adds an explicit length check that drops a too-short AppTimeAns. Note the sibling one-byte reads in the periodicity and force-resync handlers remain unguarded with the same negligible impact. | |||||
| CVE-2026-13480 | 1 Zephyrproject | 1 Zephyr | 2026-08-31 | N/A | 3.1 LOW |
| The LoRaWAN TS004 Fragmented Data Block Transport handler frag_transport_package_callback() in subsys/lorawan/services/frag_transport.c parses downlink command bytes without validating that enough payload bytes remain before each access. The loop's only bound is rx_pos < len; after consuming the one-byte command id the handler cast rx_buf + rx_pos to a 10-byte struct frag_transport_setup_req, and for a DATA_FRAGMENT command passed &rx_buf[rx_pos] to the fragment decoder, which reads exactly ctx.frag_size bytes — with no remaining-length check in either case. The fragment size is attacker-chosen in a preceding FRAG_SESSION_SETUP command (ctx.frag_size = req->frag_size, capped at CONFIG_LORAWAN_FRAG_TRANSPORT_MAX_FRAG_SIZE, default 232). rx_buf aliases the 255-byte static MacCtx.RxPayload buffer in the loramac-node MAC layer, while len is the actual decrypted payload length. By padding a downlink with mismatched-index DATA_FRAGMENT filler commands (each advancing rx_pos by three bytes without producing an answer) and appending one matching-index fragment near the end of the payload, an attacker can make the decoder read up to roughly frag_size bytes past the end of RxPayload, copying adjacent static memory into the decoder buffers and the FUOTA flash image. The handler runs only on downlinks that have already passed the LoRaWAN frame MIC and FRMPayload decryption, so the defect is reachable only by a party holding the device's session keys (the FUOTA server or an attacker who has compromised those keys). The out-of-bounds bytes are never returned to the sender — the only uplink emitted is a status answer carrying fragment counts — so there is no direct disclosure channel, and on typical flat-memory LoRaWAN MCUs the over-read stays within mapped memory, making a crash unlikely. The impact is therefore a bounded out-of-bounds read with limited confidentiality consequence and no write or control-flow primitive. The fix adds remaining-length guards before each access. | |||||
| CVE-2026-13481 | 1 Zephyrproject | 1 Zephyr | 2026-08-31 | N/A | 5.4 MEDIUM |
| The IEEE 1588 PTP management-message parser in subsys/net/lib/ptp/tlv.c mishandles the PTP_MGMT_TIME management id. In tlv_mgmt_post_recv(), the PTP_MGMT_TIME case casts mgmt_tlv->data to a 10-byte struct ptp_timestamp and reads it (then byte-swaps and writes it back) without first checking that the TLV data field is at least sizeof(struct ptp_timestamp). Every sibling management id in the same switch validates its length first; PTP_MGMT_TIME was the only case lacking that check. The length passed in is the management data size (tlv->length - 2), and the upstream guard in ptp_tlv_post_recv() only requires tlv->length > 2, while msg_tlv_post_recv() validates only that the TLV fits within the received byte count, not a per-id minimum. A peer on the local PTP segment can therefore send a PTP_MSG_MANAGEMENT message carrying a short PTP_MGMT_TIME TLV (data as small as 2 bytes), causing the parser to read and write 8 bytes beyond the validated data. The message type and TLV contents are taken straight off the wire, so the path is reachable by any adjacent attacker when CONFIG_PTP is enabled. The over-read and write-back stay within the struct ptp_msg allocation (mgmt_tlv->data lives in the leading mtu[NET_ETH_MTU] union member, so data + 10 lands at most a few bytes past mtu[], inside the same object), so this is an out-of-bounds read of adjacent in-object memory plus a bounded in-place corruption of the message's parsed timestamp, not past-allocation memory corruption. Impact is limited to minor information exposure of adjacent bytes and corruption of the device's parsed management TIME value; there is no crash on the access and no reachable reference-count corruption. The fix adds if (length < sizeof(struct ptp_timestamp)) { return -EBADMSG; } before the cast, matching the other management-id cases and fully closing the receive-path defect. | |||||
| CVE-2026-20435 | 6 Google, Linuxfoundation, Mediatek and 3 more | 40 Android, Yocto, Mt2737 and 37 more | 2026-06-17 | N/A | 4.6 MEDIUM |
| In preloader, there is a possible read of device unique identifiers due to a logic error. This could lead to local information disclosure, if an attacker has physical access to the device, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS10607099; Issue ID: MSV-6118. | |||||
| CVE-2025-20696 | 6 Google, Linuxfoundation, Mediatek and 3 more | 37 Android, Yocto, Mt6739 and 34 more | 2026-06-17 | N/A | 6.8 MEDIUM |
| In DA, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege, if an attacker has physical access to the device, with no additional execution privileges needed. User interaction is needed for exploitation. Patch ID: ALPS09915215; Issue ID: MSV-3801. | |||||
| CVE-2024-8798 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 7.5 HIGH |
| No proper validation of the length of user input in olcp_ind_handler in zephyr/subsys/bluetooth/services/ots/ots_client.c. | |||||
| CVE-2024-6444 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 6.3 MEDIUM |
| No proper validation of the length of user input in olcp_ind_handler in zephyr/subsys/bluetooth/services/ots/ots_client.c. | |||||
| CVE-2024-6443 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 6.3 MEDIUM |
| In utf8_trunc in zephyr/lib/utils/utf8.c, last_byte_p can point to one byte before the string pointer if the string is empty. | |||||
| CVE-2024-6442 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 6.3 MEDIUM |
| In ascs_cp_rsp_add in /subsys/bluetooth/audio/ascs.c, an unchecked tailroom could lead to a global buffer overflow. | |||||
| CVE-2024-6259 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 7.6 HIGH |
| BT: HCI: adv_ext_report Improper discarding in adv_ext_report | |||||
| CVE-2024-6258 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 6.8 MEDIUM |
| BT: Missing length checks of net_buf in rfcomm_handle_data | |||||
| CVE-2024-6137 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 7.6 HIGH |
| BT: Classic: SDP OOB access in get_att_search_list | |||||
| CVE-2024-6135 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 7.6 HIGH |
| BT:Classic: Multiple missing buf length checks | |||||
| CVE-2024-5931 | 1 Zephyrproject | 1 Zephyr | 2026-06-17 | N/A | 6.3 MEDIUM |
| BT: Unchecked user input in bap_broadcast_assistant | |||||