Unchecked length coming from user input in settings shell

Possible buffer overflow in ismountpoint

The hawkBit device management client in subsys/mgmt/hawkbit accumulates the body of an HTTP response from the update server into a heap buffer in responsejsoncb() (subsys/mgmt/hawkbit/hawkbit.c). The buffer is sized to hold the received body bytes but reserves no space for a terminating NUL. When the full response has arrived, the code writes responsedata[downloadedsize] = '\0' — and whenever the accumulated body length equals the allocation, that terminator lands one byte past the end of the heap object (a heap-based out-of-bounds write, CWE-122 / CWE-787).

The body length and fragmentation are taken directly from the parsed HTTP response (rsp->bodyfragstart / rsp->bodyfraglen) and are fully controlled by the remote hawkBit server, which chooses its own response length. The precise trigger depends on how the buffer grows, and both forms are remotely reachable. Since v4.0.0 the reallocation is sized to exactly downloadedsize + bodylen, so any response body larger than the 1100-byte initial buffer makes the out-of-bounds write deterministic; such response sizes are normal for hawkBit deployment metadata. Before v4.0.0 the buffer grew by doubling and the growth check ((downloadedsize + bodylen) > responsebuffersize) is false at equality, so a response body whose length is exactly the current allocation — 1100 bytes with the default initial buffer — skips the reallocation entirely and writes the terminator at responsedata[1100] of an 1100-byte object. The HTTP length-mismatch check does not catch this, because the declared and received lengths genuinely agree. Either form is reachable by a malicious, compromised, or man-in-the-middle update server (TLS is optional and, when enabled, does not protect against a hostile server), with no authentication of response content and no client-side length cap protecting the write.

The out-of-bounds write is a fixed single NUL byte immediately following the allocation, corrupting adjacent allocator metadata or the next allocation. The practical impact is heap corruption leading to denial of service (fault on a subsequent allocation or free), with the bounded, allocator-dependent possibility of further corruption. The fix sizes the buffer to the body length plus one and copies with memcpy, ensuring the terminator always lands within the allocation.

The Zephyr Project Manager plugin for WordPress is vulnerable to limited privilege escalation in all versions up to, and including, 3.3.101. This is due to the plugin not properly checking a users capabilities before allowing them to enable access to the plugin's settings through the updateuseraccess() function. This makes it possible for authenticated attackers, with subscriber-level access and above, to grant themselves full access to the plugin's settings.

On Xtensa SoCs built with CONFIGXTENSAMPU and CONFIGUSERSPACE, archbuffervalidate() in arch/xtensa/core/mpu.c — the architecture hook that verifies a user-mode-supplied buffer is accessible to the calling user thread with the requested permission — defaulted its return value to 0 (access permitted) and only set a denial result inside its per-MPU-region probe loop. When the rounded extent of the buffer wraps the 32-bit address space (size + alignment offset near SIZEMAX, or ROUNDUP(size + offset) overflowing to 0), the loop executes zero iterations and the function returns 0 = permitted without probing any MPU region.

The syscall-layer pre-checks (KSYSCALLMEMORYSIZECHECK / ZDETECTPOINTEROVERFLOW) only catch a raw addr+size wrap and do not cover the ROUNDUP-induced wrap, and the string path (archuserstringnlen -> archbuffervalidate) has no syscall-layer guard at all.

An unprivileged user-mode thread can therefore pass a crafted (addr, size) to any syscall that validates user buffers via kusermodefromcopy/tocopy or kusermodestringcopy and have validation succeed for memory it must not access; the kernel then reads from (disclosure) or, with write=1, writes to (corruption) attacker-chosen kernel or other-partition memory on the thread's behalf, enabling information disclosure, memory corruption, privilege escalation, and denial of service.

Affected from v3.7.0 (when Xtensa MPU userspace support was added) through v4.4.0. The fix changes the default to -EINVAL (deny by default), adds an explicit sizeaddoverflow check, and sets the success value only after the full range has been validated.

The userspace verifier zvrfylogfilterset() for the logfilterset syscall in subsys/logging/logmgmt.c performed a signed comparison against the int16t srcid parameter: srcid < (int16t)logsrccntget(domainid). Any negative value for srcid (e.g. -1) trivially satisfied this check and was forwarded into zimpllogfilterset, where it propagated to filterset() and ultimately to getdynamicfilter(), which uses sourceid as an unsigned index into the linker-section array &TYPESECTIONSTART(logdynamic)[sourceid].filters.

After implicit conversion through uint32t, an int16t -1 becomes 0xFFFFFFFF, indexing logdynamic far out of bounds and causing the kernel to perform an OOB read and an OOB read-modify-write (LOGFILTERSLOTGET/SET) against memory adjacent to the logdynamic 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 logdynamic) 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 CONFIGUSERSPACE=y and CONFIGLOGRUNTIMEFILTERING=y. Present from Zephyr v3.3.0 through v4.4.1. The fix replaces the signed bound check with an unsigned comparison: (uint32t)srcid < logsrccntget(domainid), which correctly rejects negative inputs.

The Classic (BR/EDR) L2CAP signaling handlers l2capbrconfreq() and l2capbrconfrsp() in subsys/bluetooth/host/classic/l2capbr.c validated the minimum command size against buf->len (the bytes remaining in the whole received PDU) instead of len (the per-command data length from the L2CAP signaling header). Because multiple signaling commands can be packed into one PDU, buf->len may exceed a command's len. An attacker can send a CONFREQ command with a header length smaller than the configuration-request structure (e.g. 0), followed by another command so that buf->len still satisfies the check. The check then passes incorrectly and optlen = len - sizeof(req) underflows the uint16t to a near-0xFFFF value. The configuration-option loop, which lacks an optlen-versus-buf->len guard, then walks far past the end of the pooled ACL receive buffer using netbuf pull primitives that perform no runtime bounds check, producing an out-of-bounds read of host memory and, when the out-of-bounds option bytes encode an MTU or flush-timeout option, an out-of-bounds write. The BR/EDR signaling channel is processed before pairing/encryption and an L2CAP channel to an L0 service such as SDP can be opened without pairing, so an unauthenticated peer within radio range that can establish an ACL connection can trigger the flaw, leading to memory corruption and denial of service (host/device crash). The defect is present in released versions including v4.4.0. The fix validates against len instead of buf->len in both handlers.

subsys/net/ip/icmpv6.c reads the network interface from a netpkt after that packet has been handed to nettrysenddata(). In icmpv6handleechorequest() and neticmpv6senderror(), the post-send statistics update calls netpktiface(reply)/netpktiface(pkt) on the just-sent packet.

The send path (nettrysenddata -> netiftx) unreferences and may free the packet back to its memory slab before returning — synchronously in the RX thread when no TX queue is configured (CONFIGNETTCTXCOUNT == 0), and asynchronously the driver/L2 may already have freed it otherwise. netpktiface() therefore dereferences a freed (and possibly reused) netpkt; with CONFIGNETSTATISTICSPERINTERFACE the stale iface pointer is further dereferenced and written through (iface->stats.icmp.sent++), turning the use-after-free read into a write through an attacker-influenceable pointer.

The core stack already documents this hazard in netcore.c ("do not use pkt after that call") and caches iface before sending; the ICMPv6 callers did not.

An unauthenticated remote attacker triggers the flaw simply by sending an ICMPv6 Echo Request (ping) or an IPv6 packet that elicits an ICMPv6 error (unknown next header, fragment reassembly timeout, destination unreachable), leading to denial of service via crash and potential memory corruption. Affected: Zephyr networking with CONFIGNETNATIVEIPV6, roughly v4.2.0 through v4.4.0.

The fix caches the interface pointer before sending and uses it for all statistics updates; the sibling commit 86e21665d46 fixes the identical bug in ICMPv4.

The UpdateHub firmware-update agent's probe handler (zimplupdatehubprobe() in subsys/mgmt/updatehub/updatehub.c) parses the JSON metadata returned by the update server into a fixed two-level nested-array struct. After parsing it validates only the outer array length (objectslen != 2) and then dereferences objects[1].objects[0].objects.sha256sum via strlen() without checking that the inner object array of element [1] is non-empty.

The metadata is attacker-influenceable network input: the agent fetches it over CoAP from the configured UpdateHub server during its routine OTA probe. A malicious or compromised update server (or, when DTLS is disabled, a network man-in-the-middle) can return a response whose second outer object array is empty. Because the parse target is zero-initialised, the corresponding objects[1].objects[0].objects.sha256sum pointer is NULL, and the subsequent strlen() dereferences address zero. The same defect exists in both the 'any boards' and 'some boards' metadata layouts.

The resulting CPU fault is fatal under Zephyr's default error handling, halting or resetting the device, so the flaw is a remotely triggerable denial of service. Impact is limited to availability; it is a read from NULL with no out-of-bounds write, memory corruption, or information disclosure. The fix rejects metadata whose inner object array is empty before any dereference, on both layouts.

Zephyr's IPv6 Neighbor Discovery send paths (netipv6sendna, netipv6sendns, netipv6sendrs in subsys/net/ip/ipv6nbr.c) updated the per-interface ICMP-sent statistics by calling netpktiface(pkt) after netsenddata(pkt) had already returned successfully. On the success path the network stack owns and releases the packet's reference (the L2/driver send unrefs it, e.g. ethernetsend -> netpktunref), so for a freshly allocated packet with refcount 1 the netpkt slab block can be freed before the statistics line runs (synchronously when no TX queue thread is configured, or via a concurrent TX thread otherwise).

The subsequent netpktiface(pkt) reads pkt->iface from the freed slab block, and with CONFIGNETSTATISTICSPERINTERFACE enabled that loaded pointer is dereferenced to increment iface->stats.icmp.sent, a use-after-free (CWE-416). If the slab block was reallocated in the meantime the read/increment targets unrelated or attacker-influenced memory, yielding corrupted statistics, a fault/crash (denial of service), or potential limited memory corruption.

The vulnerable Neighbor Advertisement path is reachable by any unauthenticated on-link node simply by sending ICMPv6 Neighbor Solicitations to a Zephyr node with native IPv6 enabled (handlensinput -> netipv6sendna).

Affected from v3.3.0 through v4.4.0; the fix uses the already-available iface argument instead of touching the sent packet. Configurations without per-interface statistics dereference only a global counter and are not affected by the memory-safety aspect.

Malformed ATAES132A responses with an oversized length field overflow a 52-byte stack buffer in the Zephyr crypto driver, allowing a compromised device or bus attacker to corrupt kernel memory and potentially hijack execution.

The CONFIGUSERSPACE syscall verifier zvrfykpoll() in kernel/poll.c allocates a kernel-side copy of the user-supplied kpollevent[] via zthreadmalloc() and then validates each event's object handle. Before this fix, validation used KOOPS(KSYSCALLOBJ(...)) inline inside the loop, which kills the calling thread without freeing eventscopy.

A user thread can pass numevents >= 1 with a forged object handle to leak the allocation; because newly spawned user threads inherit the parent's resourcepool (kernel/thread.c), an attacker spawns sacrificial threads to repeat the leak until the shared kernel heap is exhausted. Once depleted, legitimate kernel allocations from that pool (kqueue alloc nodes, kmsgq buffers, future kpoll calls, etc.) fail, causing a system-level denial of service.

The fix replaces each inline KOOPS with a conditional goto oopsfree so the buffer is freed before the thread is killed. Affects Zephyr releases from v1.12.0 (when kpoll was first exposed to user mode) through v4.4.1.

In Zephyr's Bluetooth Mesh PB-ADV provisioning bearer (subsys/bluetooth/mesh/pbadv.c), provmsgrecv() rescheduled the provisioning protocol watchdog timer unconditionally at the top of the function, before the FCS check and before the ADVLINKINVALID check. Once a provisioning attempt fails, provfailed() sets ADVLINKINVALID and the only recovery path is the protocol timer firing (protocoltimeout -> provlinkclose -> closelink -> resetadvlink and re-enabling of scanning and the unprovisioned device beacon).

A remote, unauthenticated attacker on the BLE advertising channel can first induce a provisioning failure (e.g. with a malformed generic-provisioning PDU) and then transmit any FCS-valid PB-ADV transaction PDU on the same link ID more often than once per protocol timeout (60 s, or 120 s for OOB input/output). Because each such packet reset the timer even on an invalidated link, protocoltimeout never fired, the dead link was never torn down, and the device remained pinned in an un-provisionable state with its unprovisioned beacon disabled and new Link Open requests rejected.

PB-ADV PDUs are processed without authentication and the FCS is a keyless CRC, so no pairing or prior trust is required and the attacker chooses the link ID itself. The impact is a persistent denial of provisioning/re-provisioning service; there is no memory-safety, confidentiality, or integrity impact.

The vulnerable code shipped in releases through v4.4.1. The fix moves the timer reschedule to after the ADVLINKINVALID check (and the FCS check before the reset) so an invalidated link can no longer be kept alive by incoming packets.

The Zephyr Project Manager plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘filename’ parameter in all versions up to, and including, 3.3.100 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Sierra Wireless HL7800 cellular modem driver (drivers/modem/vendorstandalone/hl7800.c, located at drivers/modem/hl7800.c in v4.4.0 and earlier) parses AT responses with roughly twenty handlers that call netbuflinearize(value, sizeof(value), buf, 0, len) into a 128-byte stack buffer and then write value[outlen] = 0. Because netbuflinearize() (lib/netbuf/buf.c) can return a count equal to its destination-length argument, a field that exactly fills the buffer makes the terminating NUL land one byte past the end, a single-byte out-of-bounds write into adjacent stack memory.

The +KCELLMEAS cell-measurement handler oncmdatcmdinforssi() is worse: it passed the wire length len as the destination size (netbuflinearize(value, len, buf, 0, len)), so a response line longer than 128 bytes overflows the value stack buffer with attacker-influenceable content. The line length comes from netbuffindcrlf(), which accumulates bytes across the whole netbuf fragment chain and is not bounded to 128, so an over-long line reaches the defect.

The data originates from the cellular modem over UART, driven by the network: operator-scan results, +CGCONTRDP IP/DNS info, socket indications, and +KCELLMEAS neighbour-cell reports. An attacker able to shape what the modem emits — a rogue base station, a compromised modem baseband, or a remote peer feeding oversized response framing — can drive a line past 128 bytes. The handlers run in the driver's RX thread in kernel context, so the corruption is kernel-side.

The +KCELLMEAS path is a full stack buffer overflow whose worst case is code execution in kernel context and whose floor is a reliable crash; the remaining sites are single-byte NUL out-of-bounds writes. Exploitation requires the modem to emit an over-long AT response line, giving high attack complexity over an adjacent (cellular radio) vector. The fix passes sizeof(dst) - 1 (and correct explicit bounds for the IMSI and +KCELLMEAS sites) so the terminator always stays in bounds.

mcumgrserialprocessfrag() in subsys/mgmt/mcumgr/transport/src/serialutil.c calls netbufreset() on the result of smppacketalloc() before checking it for NULL. smppacketalloc() uses netbufalloc(KNOWAIT) against the shared MCUmgr packet pool (CONFIGMCUMGRTRANSPORTNETBUFCOUNT, default 4), which returns NULL when the pool is exhausted. In default builds the ASSERTNOMSG in netbufreset is a no-op, so netbufsimplereset writes through the NULL pointer (buf->len = 0; buf->data = buf->buf), causing a fault/crash.

The fragment data reaches this code from attacker-controlled bytes on the MCUmgr serial/UART/shell-console transports (smpuart.c, smprawuart.c, smpshell.c), and a fresh buffer is allocated at the start of essentially every new packet. An attacker on the serial/console link can flood the transport to drive the 4-entry buffer pool to exhaustion and induce the NULL dereference, crashing the device (denial of service).

The defect was introduced after the original MCUmgr rework and shipped in Zephyr v4.4.0. The fix moves the NULL check ahead of netbufreset.

The PSA Protected Storage credential backend (subsys/net/lib/tlscredentials/tlscredentialstrusted.c) declared its credential-store mutex as a plain zero-filled static struct kmutex credentiallock; and never called kmutexinit() on it. A statically zero-filled kmutex has an uninitialized wait queue (its dlist head/tail are NULL instead of the self-referential sentinels that kmutexinit/KMUTEXDEFINE install). The uncontended lock path does not touch the wait queue, so the defect is latent and serialized use behaves correctly.

When two execution contexts contend on the lock, kmutexlock() pends the blocking thread on the wait queue via zpendcurr(), which calls sysdlistappend() on the zeroed list and dereferences a NULL tail pointer (tail->next = node), faulting the kernel. The lock is held during TLS handshake credential loading and by all credential add/get/delete operations, so a deployment performing concurrent TLS handshakes (for example a server handling multiple simultaneous connections from a remote peer) or a credential-management operation concurrent with a handshake can trigger the dereference.

The impact is a denial of service: a deterministic kernel panic / device reset on the first contention. There is no memory corruption beyond the NULL dereference and no confidentiality or integrity impact; mutual exclusion on the fast path remains correct. Exposure is limited to builds with CONFIGTLSCREDENTIALSBACKENDPROTECTEDSTORAGE enabled (PSA Protected Storage / TF-M platforms); the default volatile RAM backend initializes its lock correctly and is unaffected.

The fix initializes the mutex statically with KMUTEXDEFINE(credentiallock), providing a valid wait queue so the contended path no longer touches a NULL list.

The NXP LPUART serial driver (drivers/serial/uartmcuxlpuart.c), when CONFIGUARTUSERUNTIMECONFIGURE is enabled, called LPUARTDeinit() at the start of mcuxlpuartconfigure(), which disables the LPUART peripheral clocks. The requested configuration is validated only afterwards (in mcuxlpuartconfigurebasic), and unsupported parity/data-bit/stop-bit/flow-control values return -ENOTSUP before the clock is re-enabled.

As a result, a uartconfigure() request with an unsupported configuration left the LPUART in a clock-disabled state; any subsequent access to LPUART registers (pollout/pollin, interrupt handling, or a later reconfigure) faults on the gated peripheral and escalates to a hard fault, crashing the system.

uartconfigure() is a Zephyr syscall whose verifier (zvrfyuartconfigure) only checks that cfg is readable user memory and forwards the caller-supplied configuration unchanged, so an unprivileged userspace thread with access to an LPUART device can deterministically trigger the fault, a persistent system-wide denial of service.

Introduced in v2.5.0 and present in all subsequent releases until this fix, which removes the LPUARTDeinit() call and instead only disables the transmitter/receiver, leaving the clock running.

The USB CDC-NCM device class (subsys/usb/devicenext/class/usbdcdcncm.c) ignores the return value of usbdepenqueue() in its ethernet transmit callback cdcncmsend(). When the enqueue fails, the function still calls ksemtake(&data->syncsem, KFOREVER), blocking on a completion semaphore that is only ever signaled from the bulk-IN transfer-completion callback. Because nothing was enqueued, that callback never fires and the calling thread — a shared network traffic-class TX thread — deadlocks permanently while holding the interface TX lock, halting transmission until reboot (and leaking the transmit buffer).

The enqueue fails under conditions controlled by the attached USB host: usbdepenqueue() returns -EPERM whenever the bus is suspended (a standard, persistent host operation), and the underlying udcepenqueue() returns -EPERM/-ENODEV on disconnect, bus reset, or endpoint disable. The cdcncmsend() guard only checks the DATAIFACEENABLED and IFACEUP flags, not the suspended state, so a packet transmitted while the host holds the bus suspended reaches the failing enqueue and deadlocks the TX path.

The realistic trigger is a bus suspend that occurs while the exported network interface is active and has traffic to send — host sleep, USB selective/auto-suspend, or hub power management — after which any device-originated packet deadlocks the path, recoverable only by reboot. The impact is a persistent loss of the virtual network connection between the host's NCM interface and the Zephyr device; because the deadlocked thread is a shared traffic-class TX thread, egress on other network interfaces can stall as well. There is no memory corruption or information disclosure.

The defect was introduced with the CDC-NCM driver and shipped in releases through v4.4.0; it is fixed by checking the usbdepenqueue() return value and freeing the buffer before the blocking wait.

Zephyr's DNS resolver detects mDNS (.local) queries in dnsresolvenameinternal() (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()/dnsgetaddrinfo()/dnsresolvename() 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 kusermodestringalloccopy 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 CONFIGMDNSRESOLVER is enabled, exists since v1.10.0, and is fixed by replacing the fixed-length memcmp with a NUL-safe strcmp(ptr, ".local").

The WNC-M14A2A LTE-M modem driver mishandles unsolicited %NOTIFYEV: events in oncmdsocknotifyev() (drivers/modem/vendorstandalone/wncm14a2a.c). The response line is linearized into a fixed 40-byte stack buffer via netbuflinearize(), which caps the copy at 39 bytes and returns outlen <= 39. The two quote-delimiter scanning loops, however, were bounded by len — the full CR/LF-delimited frame length returned by netbuffindcrlf() — rather than by outlen.

When a %NOTIFYEV: line longer than 39 bytes contains no " within the linearized region, the loop indices p1/p2 walk past value[39] and read adjacent stack memory until a stray quote byte is found or the index reaches len. The over-read string is then passed to strncmp()/atoi()/LOG, and if a quote byte is found out of bounds the subsequent value[p2] = '\0' performs a single-NUL out-of-bounds stack write at an attacker-influenced offset.

The %NOTIFYEV: payload carries network-derived content (LTIME network time, SIB1 base-station system information, CSPS/RRCSTATE), so a rogue cellular base station, a malicious or compromised modem module, or RF manipulation that induces an over-long notify line reaches the defect without any application interaction; the handler runs automatically on the unsolicited event in the modem RX thread.

The impact is out-of-bounds stack disclosure (into logs and parsing) and stack corruption that can crash the modem RX thread (denial of service). The write offset is only weakly controlled, so memory-safe code execution is not demonstrated. The fix bounds both scanning loops by outlen, keeping all accesses within the linearized buffer.

The Zephyr Project Manager plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 3.3.202 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfilteredhtml has been disabled.

In subsys/debug/coredump/coredumpshell.c, printcoredumphdr() used the 16-bit tgtcode field of a stored Zephyr coredump header directly as an index into coredumptargetcode2str[], a fixed 7-element array of string pointers, with no bounds check.

A stored coredump whose tgtcode is >= 7 causes an out-of-bounds read of a char up to ~64K entries past the array; that value is passed as the %s argument to shellprint, which dereferences and walks it as a string. The result is either disclosure of device memory contents to the shell user or a crash when the out-of-bounds pointer is unmapped.

The defect is reached via the coredump print shell command (cmdcoredumpprintstoreddump -> prettyprintcoredump -> parseandprintcoredump -> printcoredumphdr). The tgtcode field is device-generated and in-range during normal crash handling, so triggering requires local shell access plus the ability to stage or corrupt the stored coredump in the flash/in-memory backend.

Introduced in v4.2.0 (commit 13abd7fe730) and present through v4.4.0; fixed by clamping out-of-range codes to the 'unknown' (index 0) entry.