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.

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.

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.

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.