Vulnerabilities

CVE-2026-13481 is an out-of-bounds read (CWE-125) in the IEEE 1588 PTP management-message parser of the Zephyr RTOS networking stack (subsys/net/lib/ptp/tlv.c), where the PTP_MGMT_TIME management id is cast to a 10-byte struct ptp_timestamp and read without first checking that the TLV data field is at least that long — the only management id in the switch missing this validation. An adjacent attacker on the local PTP segment can send a management message carrying a short PTP_MGMT_TIME TLV (data as small as 2 bytes), causing the parser to read and then byte-swap and write back 8 bytes beyond the validated data; the path is reachable whenever CONFIG_PTP is enabled. The attacker gains minor information exposure of adjacent bytes within the same message object and can corrupt the device's parsed management TIME value; there is no crash, no past-allocation memory corruption, and no reachable reference-count corruption. Only Zephyr builds with the PTP subsystem enabled are affected — a profile typical of industrial and telecom precision-timing deployments — and the Zephyr Project (the CNA) has published advisory GHSA-mh5r-jxh8-hxwx alongside the fix. Exploitation status: one public advisory/PoC reference exists, but there is no evidence of in-the-wild exploitation (EPSS 0.2%, not in CISA KEV).

Do: Upgrade to a Zephyr release that includes the upstream fix, which adds the missing guard — returning -EBADMSG when the TLV data is shorter than sizeof(struct ptp_timestamp) — in tlv_mgmt_post_recv(), and consult GHSA-mh5r-jxh8-hxwx for the exact fixed version for your branch. If patching is not immediately possible, disable CONFIG_PTP or restrict acceptance of PTP management messages to trusted adjacent peers. Given the low EPSS and absence of known in-the-wild exploitation this is not urgent, but exposed precision-timing deployments should prioritize the update.

CVE-2026-11368 is a use-after-free (CWE-416) in the Bluetooth host ATT layer of the Zephyr RTOS (subsys/bluetooth/host/att.c), where each in-flight ATT TX buffer stores a pointer to its owning channel in a static metadata array (tx_meta_data_storage[]) that is never cleared when the channel is torn down. A remote Bluetooth peer can trigger the bug by disconnecting while an ATT PDU (a notification, indication, or response) is still in flight in the controller TX path; no pairing or user interaction is required to reach the ATT bearer. The deferred buffer-destroy work then dereferences the now-dangling channel pointer, reliably crashing the Bluetooth host (denial of service) and potentially corrupting live memory if the freed channel slab slot has been reused. Any device running Zephyr firmware with the Bluetooth host stack and ATT enabled is affected, a population that includes many Bluetooth Low Energy products built on Zephyr-based vendor SDKs. No in-the-wild exploitation is known (EPSS 0.3%, not in CISA KEV), but a public advisory with a proof-of-concept reference (GHSA-85vg-gwc4-77g7) has been published by the Zephyr Project.

Do: Rebuild and re-flash affected devices with a Zephyr release that includes the fix referenced in GHSA-85vg-gwc4-77g7 (bt_att_released() now clears stale tx_meta_data_storage[] channel references before the slab slot is freed); no fixed version number is given in the available data, so verify the fix commit against the upstream advisory. Check whether your firmware build enables Zephyr's Bluetooth host (CONFIG_BT) with ATT/GATT; if Bluetooth is unused, disable it, and as an interim measure limit BLE peripheral exposure since no pairing or user interaction is needed to trigger the crash.

Zephyr RTOS's hawkBit device management client (subsys/mgmt/hawkbit/hawkbit.c) accumulates the HTTP response body into a heap buffer that reserves no room for a terminating NUL, so when the accumulated body length equals the allocation the terminator is written one byte past the end of the heap object (CWE-122/CWE-787). Since v4.0.0 any response body larger than the 1100-byte initial buffer triggers the out-of-bounds write deterministically, while pre-v4.0.0 builds are affected when the body length exactly equals the current allocation (1100 bytes by default); both cases are remotely reachable because the body length is fully controlled by the update server, and TLS does not protect against a hostile or man-in-the-middle server. An attacker controlling the update-server path gains a fixed one-byte NUL heap corruption that typically causes denial of service (a fault on a subsequent allocation or free), with bounded, allocator-dependent potential for further corruption. Only Zephyr-based devices built with the hawkBit update client enabled and configured against a remote update server are affected. The flaw is documented in a public Zephyr security advisory (GHSA-39h3-7phx-pwhv), but it is not in CISA KEV, has a low 0.3% EPSS (26th percentile), and there is no evidence of in-the-wild exploitation.

Do: Upgrade Zephyr to the patched release identified in the advisory GHSA-39h3-7phx-pwhv, which sizes the buffer to body length plus one and copies with memcpy so the terminator always lands inside the allocation. Until patched, confirm whether your builds actually enable the hawkBit subsystem (builds without it are unaffected) and harden the update-server path with TLS certificate pinning to prevent man-in-the-middle triggers, noting that TLS alone does not protect against a compromised or hostile hawkBit server. Because the impact is denial of service, prioritize devices where availability is critical.

Zephyr RTOS's experimental OCPP 1.6 client contains an out-of-bounds read and a potential one-byte out-of-bounds write in its inbound RPC message parser, caused by a hand-rolled strncpy-based extractor that can leave the 128-byte stack buffer unterminated so a subsequent strchr scans past it. A malicious or compromised OCPP central-system server, or any on-path attacker when OCPP is deployed over unencrypted ws://, can trigger the flaw by sending an RPC frame whose uid or action field is 127+ bytes with no closing quote, or by filling the receive buffer with a maximal-length frame. The primary impact is a remotely triggerable denial of service, since the unbounded scan can fault on an unmapped page and the stray NUL write can corrupt adjacent stack state; confidentiality impact is limited because the over-read bytes are not reflected to the peer. Only Zephyr builds that explicitly enable the experimental OCPP subsystem (CONFIG_OCPP), typically OCPP 1.6 charge-point or charging-infrastructure prototypes, are affected. No exploitation has been reported in the wild: the EPSS probability is low (0.3%), the flaw is not in CISA KEV, and a public reference exists in the Zephyr security advisory GHSA-jgqq-7mjj-w642.

Do: Check Zephyr security advisory GHSA-jgqq-7mjj-w642 for the affected and fixed version ranges and upgrade to a Zephyr release containing the rewritten parser, which uses bounds-respecting json_mixed_arr_parse() and an explicitly NUL-terminated uid copy. If OCPP is not required, disable CONFIG_OCPP; if it is, use wss:// (TLS) with trusted central systems to remove the on-path attack vector. Audit whether any deployed charge-point or charging-infrastructure builds enable the experimental OCPP client and are reachable from untrusted networks.

Zephyr's Bluetooth host performs its pre-send security check against the wrong GATT attribute: when an application passes the Characteristic Declaration (the documented, common idiom) to the notify/indicate APIs, the host checks the declaration's hard-coded read permission instead of the characteristic value's encryption/authentication/LESC requirements. A remote attacker within Bluetooth range connects, optionally without pairing or encryption, and writes the Client Characteristic Configuration descriptor to enable notifications or indications, causing the server to transmit the protected characteristic value over a link that never reached the required security level. The attacker gains read access to GATT characteristic values the application intended to expose only over an encrypted or authenticated link (information disclosure / access-control bypass, CWE-863); there is no memory-safety or availability impact. Any Zephyr-based Bluetooth device whose application restricts notify/indicate characteristic values to security permissions while the CCC descriptor is writable at a lower tier is affected, and the Notify-Multiple path additionally omitted the LE Secure Connections requirement. No in-the-wild exploitation is currently known (EPSS 0.2%, not in CISA KEV); the vendor advisory with a public reference (GHSA-4w3r-v9q9-4462) is available and a fix that resolves the value attribute before the permission check has been added to the host stack.

Do: Upgrade Zephyr to a release containing the fix (value-attribute resolution via bt_gatt_attr_resolve_value() and the full read-encrypt mask, including LESC, on the Notify-Multiple path) — check advisory GHSA-4w3r-v9q9-4462 for patched versions. As interim mitigations, pass the characteristic value attribute (not the Characteristic Declaration) to notify/indicate calls and set the CCC descriptor's permissions to require the same security level so peers must pair/encrypt before subscribing. Audit GATT service definitions for characteristics whose values require BT_GATT_PERM_READ_ENCRYPT/AUTHEN/LESC but whose notifications or indications could be enabled by an unencrypted peer.

Zephyr RTOS's Bluetooth host stack contains a use-after-free (CWE-416) in the GATT client's CCC-write response handler, gatt_write_ccc_rsp() in subsys/bluetooth/host/gatt.c, which invokes the application's subscribe() callback after already calling the terminating notify(conn, params, NULL, 0) that — per the documented GATT API — signals the application may free or reuse the bt_gatt_subscribe_params struct. A device within Bluetooth range acting as a GATT server can trigger the faulty ordering simply by answering the CCC write with an ATT Error Response, whose error code flows through att_error_rsp and att_handle_rsp into gatt_write_ccc_rsp; the unsubscribe path is also affected. The result is memory corruption, a crash (denial of service), or potentially attacker-influenced control flow via an indirect call through the freed params->subscribe function pointer. Any Zephyr-based product using the Bluetooth host stack as a GATT client whose application frees or recycles subscription parameters in its notification-termination handler is affected; the affected/fixed version range is not stated in the source data, so users should consult Zephyr advisory GHSA-29xh-jm2m-4qvx. Exploitation has not been reported in the wild (EPSS 0.3%, not in CISA KEV), but a public advisory with a proof-of-concept reference is available.

Do: Update affected Zephyr-based products to a firmware release incorporating the fix from Zephyr advisory GHSA-29xh-jm2m-4qvx, which reorders gatt_write_ccc_rsp so the subscribe() callback runs before the terminating notify(NULL) in both the error and unsubscribe paths. As an interim mitigation, applications can avoid freeing or reusing bt_gatt_subscribe_params in the notify-termination handler, and operators should contact device vendors to confirm their BLE stack includes the patch. Because exploitation requires a connected GATT-server peer within Bluetooth range, restricting connections to trusted peripherals reduces exposure.

The userspace verifier z_vrfy_log_filter_set() for the log_filter_set syscall in subsys/logging/log_mgmt.c performed a signed comparison against the int16_t src_id parameter: src_id < (int16_t)log_src_cnt_get(domain_id). Any negative value for src_id (e.g. -1) trivially satisfied this check and was forwarded into z_impl_log_filter_set, where it propagated to filter_set() and ultimately to get_dynamic_filter(), which uses source_id as an unsigned index into the linker-section array &TYPE_SECTION_START(log_dynamic)[source_id].filters. After implicit conversion through uint32_t, an int16_t -1 becomes 0xFFFFFFFF, indexing log_dynamic far out of bounds and causing the kernel to perform an OOB read and an OOB read-modify-write (LOG_FILTER_SLOT_GET/SET) against memory adjacent to the log_dynamic section. The written value is a constrained 3-bit log level slot within the targeted 32-bit word, but the target address is attacker-chosen (a small negative offset from log_dynamic) and the write occurs in supervisor mode following a syscall from an unprivileged user thread, providing a kernel memory-corruption / privilege-escalation primitive. The defect is reachable on any build with CONFIG_USERSPACE=y and CONFIG_LOG_RUNTIME_FILTERING=y. Present from Zephyr v3.3.0 through v4.4.1. The fix replaces the signed bound check with an unsigned comparison: (uint32_t)src_id < log_src_cnt_get(domain_id), which correctly rejects negative inputs.

In Zephyr's userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock. On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx. The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object's perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool. The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and including v4.4.0. Fixed by holding lists_lock across the bitmap RMW and the permissions clear (and inlining the obj_list traversal that previously took the lock itself).

The Zephyr ext2 file system validates the on-disk superblock in ext2_verify_disk_superblock() (subsys/fs/ext2/ext2_impl.c) before completing a mount. The validator checked the magic number, block size, revision and feature flags, but did not verify that the on-disk fields s_blocks_per_group and s_inodes_per_group are non-zero. Both fields are read directly from the image and are later used as divisors during mount-time initialization. During mount, get_ngroups() divides and modulos s_blocks_count by s_blocks_per_group (reached via ext2_fetch_block_group() from ext2_init_fs()), and get_itable_entry() divides (ino - 1) by s_inodes_per_group when fetching the root inode (both in subsys/fs/ext2/ext2_diskops.c). A superblock with either field set to zero therefore causes an integer division by zero during the mount sequence. An attacker who can present a crafted ext2 image to a device that mounts ext2 — removable media such as an SD card or a USB mass-storage device — can trigger this. On ARMv7-M / ARMv8-M-mainline Cortex-M targets, divide-by-zero trapping is enabled (SCB_CCR_DIV_0_TRP), so the division raises a UsageFault that Zephyr treats as a fatal error, producing a denial of service. The impact is limited to availability; the malformed value is consumed only as a divisor. The fix rejects a zero s_blocks_per_group or s_inodes_per_group in the superblock validator, returning -EINVAL so the mount fails before any block-group or inode I/O occurs.

The MCTP-over-I2C+GPIO target binding in Zephyr (subsys/pmci/mctp/mctp_i2c_gpio_target.c) processes pseudo-register writes from an I2C bus master byte-by-byte in mctp_i2c_gpio_target_write_received() without validating the order or the receive buffer. In the affected versions the MCTP_I2C_GPIO_RX_MSG_ADDR (data) handler dereferences and writes through b->rx_pkt without checking that the receive buffer was allocated: a controller that selects the data register and writes a byte without first sending the length register (which is what allocates the buffer) causes a write of an attacker-chosen byte through a NULL/unallocated mctp_pktbuf pointer (i.e. into a small attacker-advanceable offset above address 0), producing memory corruption or a hard fault. The same handler also performs a write-then-check bounds test, allowing a one-byte heap overflow at data[255] when more than 255 data bytes are sent. Because the I2C target callback is invoked with raw bytes supplied by whatever device is the bus master and the binding performs no authentication, a malicious or malfunctioning controller on the bus can trigger these without any prior protocol state, leading to memory corruption and/or denial of service on the target device. The vulnerable code was introduced when the I2C+GPIO target binding was added and shipped in Zephyr v4.3.0 and v4.4.0. The fix defers allocation to the first data byte with a NULL check, treats a missing length as a zero-sized packet rejected by libmctp, and moves the bounds check before the store.

The Zephyr ADIN2111/ADIN1110 10BASE-T1S/T1L Ethernet driver (drivers/ethernet/eth_adin2111.c) reassembles received Ethernet frames in OPEN Alliance (OA) SPI mode by copying device-supplied 64-byte data chunks into a fixed static buffer ctx->buf of size CONFIG_ETH_ADIN2111_BUFFER_SIZE (default 1524 bytes). In eth_adin2111_oa_data_read(), each valid chunk was memcpy'd into ctx->buf[ctx->scur] and the write cursor scur advanced, with no check that scur + len stayed within the buffer. The number of chunks (up to 255, from the BUFSTS RCA field) and the per-chunk length are taken entirely from the frame data received off the wire; the cursor is only reset on a start-of-frame chunk. An attacker on the single-pair Ethernet segment can therefore send a frame whose reassembled size exceeds the configured buffer, causing the driver's RX offload thread to write attacker-controlled frame bytes past the end of the static buffer into adjacent driver/kernel memory (up to roughly 14.8 KB in the worst case). This is a remotely/adjacently reachable out-of-bounds write (CWE-787) that can corrupt memory and cause denial of service or potentially code execution. The defect was introduced when OA SPI support was added (commit 0ca8b0756b1) and shipped in releases v3.7.0 through v4.4.0. The fix adds a bounds check that drops the oversized frame and resets the cursor before the copy.

subsys/net/lib/lwm2m/lwm2m_pull_context.c copied the firmware-update Package URI into a fixed static buffer (context.uri, size CONFIG_LWM2M_SWMGMT_PACKAGE_URI_LEN, default 128) with memcpy(context.uri, uri, LWM2M_PACKAGE_URI_LEN), copying exactly the destination size with no length validation. The Firmware-Update object stores the server-supplied Package URI (/5/0/1) in a 255-byte buffer, so a LwM2M management server (or an on-path attacker on a session lacking strong DTLS) can WRITE a URI of 128-254 characters; only the first 128 bytes are then copied into context.uri with no NUL terminator. That buffer is subsequently consumed as a C string by http_parser_parse_url(context.uri, strlen(context.uri), ...), strlen-based CoAP URI-path/PROXY-URI option appends, and lwm2m_parse_peerinfo(), causing an out-of-bounds read of adjacent static memory. The over-read bytes are appended to outbound CoAP requests (information disclosure of adjacent device memory to the server/proxy) and can crash the device (denial of service). The vulnerable copy was introduced by the pull-context refactor (first released in v3.0.0) and is present through v4.4.0; the default-on CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT path is affected. The fix adds a strlen(uri) >= sizeof(context.uri) check returning -ENOMEM and switches to strcpy(), guaranteeing a bounded, NUL-terminated buffer.

parse_ipv4() in subsys/net/ip/utils.c (reached via net_ipaddr_parse() for strings of the form "a.b.c.d:port") copies the port substring into a fixed 17-byte stack buffer (char ipaddr[NET_IPV4_ADDR_LEN + 1]) using a length of str_len - end - 1, where str_len is the full, unbounded input length and end is only the (<=15-byte) offset of the ':' delimiter. Because the destination size is never consulted, a crafted address string with a long suffix after the colon (e.g. "1.2.3.4:" followed by hundreds of bytes) causes an out-of-bounds stack write whose length and contents are fully attacker-controlled (memcpy of the suffix plus a trailing NUL), enabling memory corruption and at minimum a denial of service, and potentially control-flow hijack. The parser is reached from the standard socket API (zsock_getaddrinfo / literal-address resolution), DNS server-string configuration, and the eswifi Wi-Fi co-processor DNS-response path, so an application that resolves a network-influenced address string is exposed. The bug was introduced when the parser was added (Zephyr v1.9.0) and shipped in all releases through v4.4.0. The fix removes the unbounded copy and validates the port length before copying into a small dedicated buffer. Note: the equivalent IPv6 "[addr]:port" path in parse_ipv6() retains the same unbounded copy at this commit and remains a separate, still-reachable instance of the defect.

The Dhara flash translation layer disk driver (drivers/disk/ftl_dhara.c) implemented the dhara_nand_ callbacks so that, on a flash error, the error code was written unconditionally through the caller-supplied dhara_error_t err pointer (e.g. *err = DHARA_E_ECC in dhara_nand_read, and similar in dhara_nand_erase/prog/copy). The upstream Dhara library calls these callbacks with err == NULL along its journal-resume binary search: find_last_checkblock() invokes find_checkblock(j, mid, &found, NULL), which forwards the NULL pointer into dhara_nand_read(). This path runs during disk_ftl_access_init() -> dhara_map_resume() whenever the FTL disk is mounted/initialised. If a flash read error (uncorrectable ECC, bad block, controller error) occurs on one of the probed checkpoint pages, the driver dereferences and writes to NULL, faulting the kernel (denial of service). The trigger is conditioned on the NAND medium content/health, which can be influenced by media wear, induced faults, or a corrupted/crafted on-flash image. The fix routes all error assignments through the library's NULL-safe dhara_set_error() helper. Affects Zephyr v4.4.0, where the driver was introduced.

Zephyr's DNS resolver detects mDNS (.local) queries in dns_resolve_name_internal() (subsys/net/lib/dns/resolve.c) with memcmp(strrchr(query, '.'), ".local", 7), which always reads a fixed 7 bytes from the suffix pointer. When the resolved hostname's final label is shorter than 7 bytes (e.g. names ending in .org, .com, .net, .io, or a trailing dot), the comparison reads 1-2 bytes past the string's NUL terminator. The hostname (query) is the caller-supplied name passed through the standard getaddrinfo()/dns_get_addr_info()/dns_resolve_name() path and is influenceable by operators or remote inputs (server names from configuration, parsed URLs, or app-facing interfaces). On a tightly-sized buffer with no slack (for example a userspace getaddrinfo call where the hostname is copied with k_usermode_string_alloc_copy to exactly strlen+1 bytes), the over-read crosses the allocation boundary; if that boundary is unmapped (guard page, memory-domain boundary under MPU, or an address sanitizer) the over-read faults, causing a denial of service. The over-read bytes are never returned, so there is no information disclosure. The flaw is compiled only when CONFIG_MDNS_RESOLVER is enabled, exists since v1.10.0, and is fixed by replacing the fixed-length memcmp with a NUL-safe strcmp(ptr, ".local").

The Zephyr net_buf library (lib/net_buf/buf.c) manipulated both of its reference counts -- the per-header buf->ref and the per-data-block ref_count at the start of each variable/heap data allocation -- with plain non-atomic C operators (buf->ref++, if (--buf->ref > 0), if (--(*ref_count))). The API is documented as self-synchronizing: callers may share one buffer across threads (e.g. via k_fifo) and each holder independently calls net_buf_unref() with no surrounding lock. Under true concurrency (SMP, or single-core preemption between the non-atomic load and store while another context unrefs the same buffer), two holders can both observe the same prior reference value and both conclude they are the last reference. For heap/variable-data pools (mem_pool_data_unref/heap_data_unref, used by zbus message subscribers, the IP stack RX/TX buffers when CONFIG_NET_BUF_FIXED_DATA_SIZE=n, capture, wireguard, ISO-TP and usbip) this produces a double k_heap_free()/k_free() of the same block -- heap-metadata corruption and a use-after-free on the heap-hardening poison pattern. For the per-header refcount the buffer is returned to the pool free LIFO twice for any pool type (including fixed-data pools used by Bluetooth and networking), corrupting the free list so a later allocation hands the same buffer to two owners. The fix converts both refcounts to atomic_inc/atomic_dec (overlaying buf->ref in an atomic_t-sized union and changing the data-block refcount from uint8_t to atomic_t). Impact is gated on genuine concurrency and on an application architecture that shares one buffer among multiple independent unref'ers; the trigger is a refcount/timing race rather than packet content, so an external attacker has at most weak indirect influence over the race window. Affects all Zephyr releases through v4.4.0. This fix is not being backported to v3.7-branch (LTS). The backport was attempted and closed unmerged (#111181): the v3.7 networking tree has diverged from main, and the new atomic word-packing -- together with the assertions it adds -- turns pre-existing v3.7-only reference-counting defects elsewhere in the stack into hard faults, so landing the change faithfully would mean pulling an open-ended set of additional v3.7-only fixes into an LTS branch. v3.7 remains affected. Applications on v3.7 that share one net_buf across threads should serialize their own net_buf_unref() calls rather than rely on the documented self-synchronizing behaviour. The fix is on main and has been backported to v4.3-branch (#110852) and v4.4-branch (#110853).

Zephyr's HTTP server (subsys/net/lib/http) provides a static-filesystem resource type (HTTP_RESOURCE_TYPE_STATIC_FS, available when CONFIG_FILE_SYSTEM is enabled) that serves files from a configured root directory. Before this fix, both the HTTP/1 and HTTP/2 front-ends placed the raw, attacker-controlled request path into client->url_buffer (assembled in on_url() for HTTP/1 and copied verbatim from the :path pseudo-header for HTTP/2) without resolving ./.. segments. The static-FS handler then built the on-disk filename by directly concatenating the configured root with that raw URL (snprintk(fname, ..., "%s%s", static_fs_detail->fs_path, client->url_buffer) at http_server_http1.c:603 and http_server_http2.c:490) and opened it with fs_open(fname, FS_O_READ). Because the handler is reached via wildcard/leading-dir (fnmatch FNM_LEADING_DIR) or fallback resource matching, a request such as GET / /../../ is dispatched to the handler and, after the underlying filesystem (e.g. LittleFS/FAT) resolves the .. segments, escapes the configured web root, letting an unauthenticated remote client read arbitrary readable files on the mounted volume (information disclosure). The HTTP server requires no TLS or authentication to reach this path. The fix adds http_server_remove_dot_segments(), which canonicalizes the path portion of the URL before resource lookup in both protocol handlers, neutralizing the traversal. Affects releases v4.0.0 through v4.4.0 for deployments that register a static-filesystem resource.

Zephyr's IP socket recvmsg() implementation (subsys/net/lib/sockets/sockets_inet.c, insert_pktinfo()) validated the user-supplied ancillary (msg_control) buffer using only the payload length (msg->msg_controllen < pktinfo_len) before writing a full control message consisting of an aligned cmsg header plus the payload. Because the check omitted the cmsg header size, a control buffer whose length falls in the under-checked window (e.g. 16-27 bytes for IPv4 IP_PKTINFO on a 64-bit target, where a single element actually occupies 28 bytes) passes the guard yet causes a fixed-size out-of-bounds write of up to one cmsg header (~12 bytes) past the end of the buffer. Under CONFIG_USERSPACE the recvmsg verifier allocates a kernel-heap copy of the control buffer sized to msg_controllen and runs the implementation against it, so the overflow corrupts kernel heap memory and is triggerable from an unprivileged userspace thread; in supervisor mode it corrupts the caller's buffer. The path is reachable on a UDP/IP socket with IP_PKTINFO/IPV6_RECVPKTINFO (or hoplimit/timestamping) enabled when the application calls recvmsg() with an undersized control buffer and a datagram is received; part of the overwritten bytes (the destination IP in ipi_addr) is influenced by the received packet. The fix makes the capacity check use NET_CMSG_SPACE(pktinfo_len) (aligned header + aligned data) and returns -ENOMEM when the buffer is too small. Affected: v3.6.0 through v4.4.0.

Zephyr's IPv6 network stack can be prevented from receiving or processing future incoming packets by sending a small number of maliciously fragmented IPv6 packets. When such a packet is handled by the fragment-header processing path, the associated RX network packet buffer (allocated from a memory slab) is not released back to the pool. Repeating the malicious packet exhausts all RX buffer slots, after which the device can no longer obtain RX buffers and stops receiving traffic, resulting in a denial of service.

The Zephyr PL011 UART driver (drivers/serial/uart_pl011.c) contains an unbounded software loop in pl011_irq_tx_enable() that repeatedly invokes the interrupt-driven application callback while the TX interrupt mask bit (PL011_IMSC_TXIM) is set, to work around the controller's level-transition TX-interrupt behavior. When CTS hardware flow control is enabled (devicetree hw-flow-control or runtime UART_CFG_FLOW_CTRL_RTS_CTS) and the wired serial peer de-asserts CTS, the controller stops draining the TX FIFO; pl011_fifo_fill() then returns 0 on every call while the application still has pending data and therefore never disables the TX interrupt. The loop condition never clears, so the thread that called uart_irq_tx_enable() (e.g. h4_send() in the Bluetooth HCI H4 driver) spins indefinitely, hanging the executing context and stalling the transport — a denial of service (CWE-835). An attacker controlling the device attached to the UART's CTS line can trigger the hang by withholding CTS during transmission. Because that peer is the device wired to the UART — which may be a removable or external module (e.g. an off-board Bluetooth controller on the HCI H4 link) rather than a permanently-bonded on-PCB part — the attack vector is scored Adjacent (AV:A) rather than Physical; the security subcommittee should confirm the vector against the specific deployment. Impact is availability only; there is no memory-safety, confidentiality, or integrity consequence. The vulnerable loop was introduced in commit b783bc8448ef (Feb 2025) and shipped in releases v4.1.0 through v4.4.0. The fix breaks out of the loop when CTS is blocking and arms the CTS modem-status interrupt to resume transmission when CTS re-asserts.