The OSDP Control Panel reply parser cpdecoderesponse() in subsys/mgmt/osdp/src/osdpcp.c decodes replies from a Peripheral Device into a stack-allocated struct osdpevent. For the REPLYKEYPPAD and REPLYRAW reply types, the payload length is taken from the received frame and the only validation performed is that the declared length is self-consistent with the number of payload bytes present in the frame. Because the attacker controls both the length field and the frame length, that check imposes no bound, and the subsequent memcpy() writes into the fixed 64-byte data arrays of struct osdpeventkeypress / struct osdpeventcardread (OSDPEVENTMAXDATALEN). The sibling REPLYFMT handler in the same switch already carried the missing > OSDPEVENTMAXDATALEN bound.
The defect is reached from cpprocessreply(), which reads bytes from the OSDP RS-485 channel and passes them through osdpphycheckpacket() and osdpphydecodepacket() before dispatching on the reply ID. Triggering it requires CONFIGOSDP with CONFIGOSDPMODECP and an application event callback registered (the normal Control Panel integration), plus a frame carrying a correct SOM, a valid CRC-16, and a matching 2-bit sequence number — all of which are computable or observable by anyone on the bus. No check ties the reply ID to the outstanding command, so an oversized REPLYKEYPPAD or REPLYRAW is accepted as the answer to a routine CMDPOLL. A malicious or compromised card reader, or anyone with access to the RS-485 wiring, can supply such a frame; CONFIGOSDPSCENABLED only helps while a secure channel is active, and a single unauthenticated frame carrying a bad MAC causes scdeactivate(), after which plaintext replies are again accepted.
With the default CONFIGOSDPUARTBUFFERLENGTH of 256, roughly 180 bytes of fully attacker-chosen data can be written past the end of the stack-allocated event object, over saved registers and the return address on typical Cortex-M and RISC-V frame layouts (Zephyr does not enable stack canaries by default). The impact ranges from a hard crash of the access-control panel to potential control-flow hijack in the context of the OSDP receive thread. The fix adds an OSDPEVENTMAXDATALEN bound to both handlers, capping each memcpy() at the size of its destination.
ethernetrecv() in subsys/net/l2/ethernet/ethernet.c validates only that the first netbuf of a received frame holds a plain 14-byte struct netethhdr. When the ethertype is 0x8100 and VLAN is enabled on the interface, the same buffer is reinterpreted as the 18-byte struct netethvlanhdr without re-checking the length: the VLAN TCI and the inner ethertype are read from offsets 14..17, past pkt->buffer->len, and hdrlen is raised to 18 so the subsequent netbufpull() removes more bytes than the buffer holds.
A single unauthenticated frame of 14 to 17 bytes carrying the VLAN ethertype triggers this. No knowledge of the node's VLAN configuration is needed: netethgetvlaniface() returns the base interface for the priority tag 0, and a broadcast destination address satisfies the "frame is for me" test, so a 16-byte broadcast frame with ethertype 0x8100 and TCI 0x0000 reaches the pull. Nothing in the receive path enforces the 60-byte Ethernet minimum — the USB CDC ECM and CDC NCM gadget classes in particular hand host-supplied frames of any non-zero length straight to netrecvdata().
With assertions enabled, netbufsimplepull() asserts and the node panics. In a production build (assertions and CONFIGNETBUFHARDENING off) the uint16t buffer length underflows to 65534 and buf->data is advanced past the end of the fragment's storage, so every later parser reads far outside the buffer and any netbufadd() on that fragment computes tailroom from the underflowed length. The result is a reliable remote denial of service and out-of-bounds access with information-disclosure and corruption potential.
Only configurations built with CONFIGNETVLAN=y that have a VLAN enabled on the receiving Ethernet interface, and whose MAC does not strip VLAN tags in hardware (ETHERNETHWVLANTAGSTRIP), are affected. The fix rejects the frame before the tag is read, so hdrlen is thereafter either 14 or 18 with both sizes validated against pkt->buffer->len.
i2sesp32triggercheck() in drivers/i2s/i2sesp32.c validates the requested direction only for I2SDIRBOTH. The I2SDIRRX and I2SDIRTX branches read devcfg->rx.data->configured / devcfg->tx.data->configured without first checking the stream pointers. The device instantiation macro I2SESP32STREAMINIT() sets both .conf and .data to NULL for a direction the devicetree does not describe, so on an instance that wires only one direction — the normal shape for audio output or a worldsemi,ws2812-i2s LED strip — the other direction dereferences a NULL pointer instead of returning an error.
i2strigger() is a Zephyr syscall, and zvrfyi2strigger() in drivers/i2s/i2shandlers.c validates only the device object and the presence of the trigger API pointer; the dir argument is passed to the driver unvalidated. On a build with CONFIGUSERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2strigger() call naming the unwired direction and cause a load from address 0 in kernel mode. Among the Espressif parts that carry this driver, userspace is available in-tree only on RISC-V SoCs with CONFIGRISCVPMP, and v4.4.0 is the first release where that is buildable: the ESP32-C6 HPCORE selects RISCVPMP when it is not built for MCUboot. ESP32-C5 in v4.4.x carries the same PMP-region and userspace linker support but does not select RISCVPMP by default. Espressif Xtensa targets do not support Zephyr userspace, and in a non-userspace build the bad direction can only come from in-kernel application code.
The impact is limited to availability: the access is a read at offset 0 of the missing stream structure, so there is no attacker-controlled offset, no write primitive and no information disclosure. With the default fatal-error handler the resulting exception halts the system, giving an unprivileged user-mode thread a system-wide denial of service. The fix adds the same pointer check the I2SDIRBOTH branch already performed and returns -ENOSYS for a direction the instance does not implement; the driver's other entry points (i2sesp32configcheck(), i2sesp32configget(), i2sesp32read(), i2sesp32write()) already guarded the pointers, and a static audit found no equivalent unguarded path.
The driver defect is older than the affected range. The unguarded dereference is present from v4.2.0 (reached through i2sesp32triggerstream(), whose if (stream) guard tests the address of a struct member and is never false) and takes its present i2sesp32triggercheck() form in v4.3.0. No in-tree Espressif configuration before v4.4.0 can run a user-mode thread, so in v4.2.x and v4.3.x the direction argument can only come from trusted kernel code. Those releases carry the bug but are not listed as affected; the fix has also been merged to v4.3-branch as hardening.
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.
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.
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.
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.