parsewriteop() in subsys/net/lib/lwm2m/lwm2mmessagehandling.c handles inbound CoAP WRITE/CREATE requests that carry a Block1 option. For the first block of a transfer it called initblockctx() and then immediately stored the peer-selected block size with blockctx->ctx.blocksize = blocksize before inspecting the return code. initblockctx() sets the caller's pointer to NULL and returns -ENOMEM when no entry of the static block1contexts[] pool is free or timed out, so that store dereferences a NULL pointer.

The pool holds CONFIGLWM2MNUMBLOCK1CONTEXT entries (default 3) and an entry is only reclaimed once its transfer completes, fails, or ages past 30 seconds. A peer that reaches the client's LwM2M socket can therefore start three block-wise writes on three distinct object paths with the CoAP More bit set and leave them incomplete, then send the first block of a fourth write on a new path to reach the unguarded dereference. Reachability is gated only by the connected UDP socket's source-address filter unless CONFIGLWM2MDTLSSUPPORT is enabled — which has no default — so in a NoSec deployment an on-path or address-spoofing attacker needs no credentials; the same sequence is also reachable from a bootstrap or lower-trust server, and can be hit accidentally by a legitimate server running four concurrent block transfers.

The write targets a fixed low address with a value between 0 and 7, so the consequence is a fatal memory fault (BusFault or corrupted low memory leading to a fault) rather than a usable memory-corruption primitive: the device crashes or resets. Confidentiality and integrity are not affected. The fix moves the store below the guard and validates the context pointer itself instead of the return code, so the context is only touched once it is known to be valid.

The MCUmgr SMP-over-console transport decodes a base64 frame, reads a 16-bit packet length from it, verifies a CRC and then unconditionally strips the trailing CRC with rxctxt->nb->len -= 2U; in mcumgrserialprocessfrag() (subsys/mgmt/mcumgr/transport/src/serialutil.c). mcumgrserialextractlen() accepted any declared length, including 0 and 1, and a packet declaring length 0 passes the checksum test for free because crc16itut() over zero bytes returns the zero seed. Since netbuf::len is a uint16t, the subtraction underflows and the buffer is handed to SMP claiming roughly 65 KB of payload while its data area is only CONFIGMCUMGRTRANSPORTNETBUFSIZE bytes (default 384).

The trigger is a single unauthenticated 7-byte line on the management console — the 0x06 0x09 packet marker followed by the base64 group AAA= and a newline — delivered to any transport built on this helper: CONFIGMCUMGRTRANSPORTUART (smpuart.c) or CONFIGMCUMGRTRANSPORTSHELL (smpshell.c), both of which select MCUMGRTRANSPORTSERIALHASSMPOVERCONSOLE. No prior session state, fragmentation or credentials are required to trigger the underflow, and the malformed frame is mishandled before any command handler or command-level access control runs. The attacker only needs write access to that console, which on many boards is a USB CDC-ACM port rather than a bare UART header.

With the inflated length, smpprocessrequestpacket() in subsys/mgmt/mcumgr/smp/src/smp.c loses its bound: cbornbreaderinit() gives the CBOR decoder a ~65 KB window into a 384-byte buffer, and each request header's nhlen is checked only against the inflated length. On its own the 7-byte frame re-parses whatever stale bytes the reused pool buffer still holds, typically a replay of the previously received request followed by a parse error, without leaving the buffer. Because the transport is unauthenticated, though, the attacker also controls the frames sent before the trigger, and can stage buffer contents so that a request succeeds with an nhlen larger than the buffer; netbufpull(), guarded only by ASSERTNOMSG, then moves the parse cursor out of bounds and the loop reads further headers and CBOR from adjacent memory. The consequence is an out-of-bounds read that can fault the MCUmgr thread (denial of service); memory disclosure is also possible, since the default-enabled os echo handler (CONFIGMCUMGRGRPOSECHO) decodes its string inside that window and copies it into its response. There is no integrity gain beyond what the unauthenticated transport already permits.

The fix rejects any declared packet length of two bytes or fewer in mcumgrserialextractlen(), so the CRC-strip subtraction can no longer underflow. The identical pattern remains in the test-only loopback transport subsys/mgmt/mcumgr/transport/src/smpdummy.c (CONFIGMCUMGRTRANSPORTDUMMY), which has no external input path and therefore carries no practical exposure.

The native BSD-socket layer recorded a pending asynchronous socket error by type-punning it into struct netcontext's void userdata field (ctx->userdata = INTTOPOINTER(-status) in zsockacceptedcb(), zsockreceivedcb(), zsockconnectedcb() and zsockclosectx() in subsys/net/lib/sockets/socketsinet.c), reading it back with POINTERTOINT(). That same field is owned by the network stack for listening TCP contexts: nettcpaccept() stores the parent context pointer there and the TCP core passes it back to the registered accept callback. A failed accept therefore left a small integer (an errno value) where the stack expected a struct netcontext .

When the network interface carrying a listening TCP socket goes down, closetcpconn() in subsys/net/ip/tcp.c invokes the accept callback with -ENETDOWN and the context's userdata. In v4.3.0 the callback was not disarmed afterwards, so a second interface-down event forwarded the previously stored errno to zsockacceptedcb(), which dereferenced it as the parent context and performed several stores through it (sockseterror()'s read-modify-write of socketdata, kfifocancelwait(&parent->recvq)) — the crash described in the fix's commit message. v4.3.1 and v4.4.x carry a later change clearing conn->acceptcb after the error callback (269cb8823d3 on the v4.3 branch, 913fae5169425550f2364655298fceb79b320066 on main), which closes that repeat path; on those releases the poisoned cookie remains reachable only by a narrower race, a handshake completing alongside the interface-down still passing the stale cookie to kfifoput(&parent->acceptq, ...), and by getsockopt(SOERROR), which reads the field back unconditionally.

On v4.3.0 an application that keeps a listening TCP socket open across repeated link-down events is sufficient to reach the defect; the triggering condition is a network-interface state change, not attacker-supplied packet data, so the practical attacker is one able to force the link down repeatedly (for example an adjacent attacker disrupting a wireless link) or one with local/physical access. Because both the faulting address and the stored data are fixed small constants derived from the errno value, the outcome is a wild-pointer access leading to a kernel fatal error — a denial of service (device crash or reset) rather than an attacker-directed memory corruption.

The fix stores the pending error in a dedicated netcontext.sockerror field and converts every producer and consumer to sockseterror()/sockgeterror(), leaving userdata untouched. As a side effect it also stops getsockopt(SOERROR) — which is evaluated unconditionally — from returning the kernel address held in userdata to a userspace application.

The CoAP link-format helper matchpathuri() in subsys/net/lib/coap/coaplinkformat.c compares a registered resource path against the URI carried in a Uri-Query href= option. That URI is not NUL terminated, but the inner character loop advanced its index k once per path character without ever testing it against the option length len. When a registered path segment is longer than the supplied URI and the URI is a prefix of it, the loop reads uri[len] and beyond, past the end of the option value.

The path is reached from coapwellknowncoregetlen() and coapwellknowncoreget() via matchqueriesresource(), i.e. by any unauthenticated GET /.well-known/core?href=/<prefix> request to a device that serves /.well-known/core (for the CoAP server subsystem, CONFIGCOAPSERVERWELLKNOWNCORE, default y) and has at least one resource that declares struct coapcoremetadata attributes.

The over-read does not reach the receive buffer. The well-known-core builders parse the query into a stack-local struct coapoption, whose value is a fixed array (value[12], or CONFIGCOAPEXTENDEDOPTIONSLENVALUE bytes) that the option bytes are copied into, so uri points into that copy. Reading past len therefore reads the unused, uninitialized tail of the array and, when the option fills it, the bytes just past it in the same stack frame. (In the ZoAP library of v1.8.0 to v1.9.x the option value was instead a pointer into the received packet, and the over-read ran past the option inside the packet buffer.)

The impact is bounded. The number of bytes read past the end is limited by the length of the resource path segment, and each additional byte is only read if it happens to equal the next path character, so in practice the over-read is one byte. It also cannot influence the response: returning a match requires the final compared index to be len - 1 or len, both in bounds, so out-of-bounds bytes only ever steer the loop to the next candidate resource. The consequence is undefined behaviour, not information disclosure and not a matching error.

The fix adds a k >= len guard at the top of the inner loop, so every uri[k] dereference is within the option value while still allowing a trailing wildcard to match a longer path.

The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffersize field of struct adcsequence in include/zephyr/drivers/adc.h documents that "the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough". The ADI MAX32 driver did not honour that contract. startread() in drivers/adc/adcmax32.c compared buffersize, a byte count, against a sample count ((1 + extrasamplings) channels), ignoring sizeof(uint16t), so it accepted a buffer half the required size. The samples are then stored through the uint16t data->buffer by WrapMXCADCGetData(), which writes two bytes per sample and advances the pointer by one uint16t: in adcmax32startchannel() for synchronous reads, and in adcmax32isr() for asynchronous ones. A sequence selecting two channels with a two-byte buffer, for example, passes the check and has its second sample written past the end of the buffer.

On a build with CONFIGUSERSPACE, adcread() and adcreadasync() are system calls. The handler in drivers/adc/adchandlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffersize) is writable by the calling thread, and rejects a user-supplied options->callback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to a MAX32 ADC device object therefore fully controls channels, buffer, buffersize and options->extrasamplings, and can make the driver write twice as many bytes as its buffer holds. Because the check scales with extrasamplings, the overrun equals the length of the buffer itself, up to channels 65536 bytes past its end, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.

The resulting stores are performed by the driver in kernel mode (in the system call itself, the ADC context timer, or the ADC interrupt handler for asynchronous reads), where the MPU does not restrict the thread's memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIGUSERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.

The fix replaces that check in startread() with a call to the new shared helper adcsequencevalidatebuffer() in drivers/adc/adccommon.c, passing sizeof(uint16t) as the sample size. The helper computes activechannels sizeof(uint16t) (1 + extrasamplings) and returns -ENOMEM before any sampling is started.

The ADC API requires each driver to reject a sampling sequence whose destination buffer is too small: the buffersize field of struct adcsequence in include/zephyr/drivers/adc.h documents that "the driver must ensure that samples are not written beyond the limit and it must return an error if the buffer turns out to be not large enough". The NXP MCUX LPADC driver did not honour that contract. mcuxlpadcstartread() in drivers/adc/adcmcuxlpadc.c performed no buffer-size check at all before assigning data->buffer = sequence->buffer. Each completed conversion then stores one 16-bit sample per enabled channel per sampling round through an unbounded data->buffer++: in mcuxlpadcisr() for interrupt-driven builds, and in mcuxlpadcdmacallback() for DMA-driven builds on releases that have the DMA path. A sequence selecting two channels with a two-byte buffer, for example, has its second sample written past the end of the buffer.

On a build with CONFIGUSERSPACE, adcread() and adcreadasync() are system calls. The handler in drivers/adc/adchandlers.c copies the sequence in from user memory, verifies only that [buffer, buffer + buffersize) is writable by the calling thread, and rejects a user-supplied options->callback; it deliberately leaves the size arithmetic to the driver. A user-mode thread that has been granted access to an LPADC device object therefore fully controls channels, buffer, buffersize and options->extrasamplings, and can request far more samples than its buffer can hold: up to channels 65536 samples into a two-byte buffer, since the sample pointer is only rewound on a repeat sampling, never on the extra samplings of a sequence.

The resulting stores are performed by the driver in kernel mode (in the ADC interrupt handler or the DMA completion callback), where the MPU does not restrict the thread's memory domain, so the write walks linearly out of the user partition and into adjacent memory such as other partitions, kernel data or thread stacks. The impact is kernel-memory corruption of attacker-chosen length at an attacker-chosen offset, a plausible privilege-escalation and denial-of-service primitive from an unprivileged user-mode thread. Builds without CONFIGUSERSPACE are affected only as a caller-side robustness defect, since the application itself supplies the buffer.

The fix calls the new shared helper adcsequencevalidatebuffer() in drivers/adc/adccommon.c from mcuxlpadcstartread(). The helper computes activechannels sizeof(uint16t) (1 + extrasamplings) and returns -ENOMEM before any sampling is started.

The userspace verifier zvrfyrtiosqecopyingethandles() in subsys/rtio/rtiosyscalls.c (subsys/rtio/rtiohandlers.c before v4.3.0) validated the RTIO object handle and the sqes input array, but not the handle out-parameter. On the first loop iteration it executed handle = sqe, storing the kernel address of the newly acquired submission-queue entry through a pointer taken verbatim from user mode, with no KSYSCALLMEMORYWRITE check in front of it.

Any user-mode thread that has been granted a struct rtio kernel object can invoke the syscall with an arbitrary address in handle. That is the ordinary way an unprivileged thread uses the RTIO API, for example via sensorreadasyncmempool() or the async ADC helpers, which call rtiosqecopyingethandles() internally. The store happens in supervisor mode before any submission-entry validation, so it fires regardless of whether the SQE contents are subsequently rejected. Only builds with CONFIGUSERSPACE and CONFIGRTIO are affected; without CONFIGUSERSPACE the verifier is not compiled and the caller is already privileged.

The write address is fully attacker-chosen and the written value is a pointer into the caller's own RTIO ring, whose contents the caller controls (the following sqe = sqes[i] copies an attacker-supplied struct rtiosqe into that slot). This yields a write-what-where primitive placing a pointer to attacker-controlled data at any kernel address, sufficient to corrupt kernel function pointers, thread structures, or memory-domain partition tables, and thus to escalate from user mode to kernel mode, defeating the isolation boundary CONFIGUSERSPACE is meant to enforce. At minimum it is a reliable kernel memory-corruption and crash primitive. The reporter reproduced the write on qemux86: a KUSER thread changed a supervisor global from NULL to a live kernel SQE pointer.

The fix adds KSYSCALLMEMORYWRITE(handle, sizeof(handle)) (guarded by the existing optional-NULL semantics) before the loop, so the destination must lie in the calling thread's writable memory domain or the thread is terminated by KOOPS. The neighbouring verifier zvrfyrtiocqegetmempoolbuffer(), which checked its buff/bufflen out-parameters only for read although the implementation writes through them, was hardened separately by bea93400138 ("rtio: syscalls: validate output params as writable"); that residual was materially weaker, since a read check still confines the target to the caller's own memory domain.

netifipv6calcreachabletime() in subsys/net/ip/netif.c derives a randomized ND reachable time from ipv6->basereachabletime as minreachable + sysrand32get() % (maxreachable - minreachable), where minreachable = base/2 and maxreachable = 3base/2 using integer division. When basereachabletime is 1, both minreachable and the modulus collapse so the function returns 0, and netifipv6setreachabletime() stores that 0 into ipv6->reachabletime.

The basereachabletime is attacker-controlled: handlerainput() in subsys/net/ip/ipv6nbr.c accepts the Reachable Time field of an incoming Router Advertisement whenever it is nonzero and <= MAXREACHABLETIME, so a single unauthenticated, link-local RA carrying a Reachable Time of 1 drives the computed reachable time to 0. Router Advertisements are unauthenticated by default and require only adjacency to the target link.

When a neighbor is subsequently confirmed reachable, netipv6nbrsetreachabletimer() reads the value and executes NETASSERT(time, "Zero reachable timeout!"). On builds with CONFIGASSERT enabled this triggers a fatal kernel assertion — a remote denial of service; on builds without assertions the reachable timer is armed with KMSEC(0) and fires immediately, forcing reachable neighbors into perpetual re-solicitation (STALE), degrading Neighbor Discovery. The impact is limited to availability; there is no memory-safety, confidentiality, or integrity consequence.

The Bluetooth Classic (BR/EDR) L2CAP receive handler btl2capbrrecv() in subsys/bluetooth/host/classic/l2capbr.c dispatched inbound data PDUs based only on the destination channel ID, without checking that the target channel had reached the BTL2CAPCONNECTED state. A dynamic channel is assigned its RX CID and added to the connection's channel list while still in BTL2CAPCONNECTING (and later BTL2CAPCONFIG) — before configuration completes and, for PSMs that require security, before the peer is authenticated (l2capbrconnreq()).

Because the channel is already findable by btl2capbrlookuprxcid() during this window, a remote peer within radio range can send a data PDU addressed to that CID and have it processed on a not-yet-established channel. The dispatch keys off channel fields (BRCHAN(chan)->rx.mode, rx.mps) that are only initialized during configuration by l2capbrconf(); since channel objects are pooled and btl2capbrchandel() does not reset rx.mode or the reassembly buffer sdu, a reused channel can carry stale state into the CONNECTING window and route the frame into the retransmission/flow-control path (btl2capbrretfcrecv()) with stale parameters and a possibly stale sdu pointer.

The impact is delivery of attacker data to upper-layer protocol handlers on a half-open (and possibly unauthenticated) channel, plus operation on stale or partially initialized channel state on reused channel objects — leading to channel/link teardown (denial of service) and, in the stale-sdu case, a dangling-pointer condition. The fix adds an explicit BRCHAN(chan)->state < BTL2CAPCONNECTED guard that drops any data received before the channel is fully connected.

On the Zephyr ARM port, enabling the hardware FPU (CONFIGFPU) forces the "Floating point ABI" choice, which defaults to CONFIGFPHARDABI. Both FPHARDABI and FPSOFTABI permit the compiler to emit hardware FP instructions in any function, even code that never uses floating-point types. However, the callee-saved FP registers (s16-s31 / d8-d15) are only saved and restored across a context switch when CONFIGFPUSHARING is enabled (arch/arm/core/cortexm/swaphelper.S and arch/arm/core/cortexar/swaphelper.S), and prior to this fix selecting an ABI did not enable FPU register sharing, which defaults off.

In a build that enables the FPU with the default ABI but leaves CONFIGFPUSHARING disabled, the kernel preserves no callee-saved FP register state across thread switches. The documented precondition for this "unshared" mode — that only a single thread ever executes FP instructions — is silently violated because the compiler may generate FP instructions in every thread.

Under CONFIGUSERSPACE, where threads are mutually isolated, this becomes an information-disclosure boundary crossing: a victim thread can leave secret-derived values in s16-s31, and a co-resident unprivileged thread can read those registers directly (FP register access is not privilege-gated), recovering data left behind by another thread. Without userspace the same defect causes cross-thread FP state corruption (a correctness fault). The leak is bounded to the 16 callee-saved single-precision registers and is opportunistic, so impact is low.

The fix makes FPHARDABI and FPSOFTABI select CONFIGFPUSHARING and tags every thread with KFPREGS at creation, so callee-saved FP state is always preserved across context switches whenever the compiler may emit FP instructions.

The OCPP 1.6 client in subsys/net/lib/ocpp parsed inbound WAMP RPC frames in parserpcmsg() (subsys/net/lib/ocpp/ocppj.c) using a hand-rolled helper, extractstringfield(), that copied the message's uid and action fields with strncpy(outbuf, token + 1, outlen - 1) and then scanned the result with strchr(outbuf, '"'). Because strncpy does not NUL-terminate the destination when the source is at least outlen - 1 (127) bytes long, the subsequent strchr reads past the 128-byte destination buffer into adjacent stack memory; if a " byte is found beyond the buffer, a one-byte out-of-bounds NUL write also occurs. A related defect in extractpayload() runs strchr/strrchr over the receive buffer, which may not be NUL-terminated when a maximal-length frame fills it.

The parsed bytes come directly from the OCPP central-system server over a websocket: the reader thread fills recvbuf via websocketrecvmsg() and calls parserpcmsg() on each inbound DATA frame (subsys/net/lib/ocpp/ocpp.c). A malicious or compromised central server, or an on-path attacker (OCPP is commonly deployed over plain ws://), can send an RPC frame whose uid or action field is 127+ bytes with no closing quote, triggering the out-of-bounds access.

The primary impact is a remotely triggerable denial of service: the unbounded scan can fault on an unmapped page, and the stray NUL write can corrupt adjacent stack state. The over-read data is not reflected to the peer, so disclosure is limited. The feature is EXPERIMENTAL and must be explicitly enabled (CONFIGOCPP). The fix replaces the manual parser with the bounds-respecting jsonmixedarrparse() and copies the extracted uid with an explicitly NUL-terminated buffer, eliminating both over-reads.

The Dhara flash translation layer disk driver (drivers/disk/ftldhara.c) implemented the dharanand callbacks so that, on a flash error, the error code was written unconditionally through the caller-supplied dharaerrort err pointer (e.g. err = DHARAEECC in dharanandread, and similar in dharananderase/prog/copy).

The upstream Dhara library calls these callbacks with err == NULL along its journal-resume binary search: findlastcheckblock() invokes findcheckblock(j, mid, &found, NULL), which forwards the NULL pointer into dharanandread(). This path runs during diskftlaccessinit() -> dharamapresume() 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 dharaseterror() helper. Affects Zephyr v4.4.0, where the driver was introduced.

Zephyr's dynamic kernel-object disposal path unrefcheck() in kernel/userspace/userspace.c frees an object's storage (kfree(dyn->data)) once its reference count reaches zero, after running a per-object-type cleanup. The cleanup switch handled only KOBJMSGQ and KOBJSTACK; there was no KOBJTIMER case. A dynamically-allocated, initialized, and armed ktimer keeps its embedded struct timeout dnode linked in the global timeout queue (timeoutq), so freeing the timer storage without cancelling the timeout leaves a dangling node in that queue.

When the timer next expires, the timeout machinery walks timeoutq and invokes ztimerexpirationhandler() on the freed node, dereferencing and writing freed (and reusable) kernel heap in kernel/ISR context. This is a deterministic use-after-free that does not depend on SMP: the queued node is simply never unlinked at free time.

The disposal is reachable from an unprivileged user thread under CONFIGUSERSPACE + CONFIGDYNAMICOBJECTS: a thread that holds the last permission on such a timer drops it via the kobjectrelease() syscall (or by exiting, through kthreadpermsallclear()), and can arm the timer itself via the ktimerstart() syscall. The free and the expiration handler run at kernel privilege while the actor is a user thread, so the bug is a sandbox-escape memory-corruption primitive usable for privilege escalation. The fix adds ktimercleanup() (cancel the timeout and wait for any in-flight handler) and calls it for KOBJTIMER before freeing.

The virtio PCI driver (drivers/virtio/virtiopci.c) parses a device's PCI capability list during driver initialization. In virtiopcireadcap() the device-supplied capability length byte caplen (read from PCI config space via pcieconfread()) was only checked with assert(tmp.caplen == capstructsize). That assert resolves to ASSERTNOMSG(), gated by CONFIGASSERT, which defaults off in production builds, so the value reached the copy logic completely unvalidated.

The length then drives a loop that copies extra capability dwords into a fixed-size stack buffer supplied by the caller. A caplen below the 24-byte base struct virtiopcicap underflows the unsigned extradatawords count to a near-SIZEMAX value, producing an effectively unbounded stack write; a caplen above the caller's buffer (up to 255) writes up to roughly 228 bytes of device-controlled data past the buffer. Both are out-of-bounds writes of attacker-controlled content executed in kernel mode during boot-time device probe.

The input originates from the virtio device. In the common deployment where Zephyr runs as a guest under a hypervisor, the device backend is the host, which already fully outranks the guest, so the bug yields no privilege escalation. The exploitable case is a virtio device that is untrusted relative to the Zephyr kernel — an untrusted or physical/passthrough virtio PCIe device on a bare-metal system, or a confidential-computing posture where the guest must defend against the host — where a malicious device can corrupt the kernel stack and potentially achieve code execution or a crash.

The fix replaces the compiled-out assert with a runtime range check rejecting caplen outside [sizeof(struct virtiopcicap), capstructsize] before any arithmetic or copy.

In Zephyr's userspace dynamic-objects subsystem, threadidxalloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global threadidxmap[] bitmap without holding listslock.

On SMP systems, two user-mode threads invoking the kobjectalloc(KOBJTHREAD) 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 KOBJTHREAD objects are then assigned the same threadid, 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 threadidxfree() can also leak entries from the thread-index pool.

The defect is reachable from any user-mode thread via the unrestricted syscall kobjectalloc and is gated on CONFIGUSERSPACE, CONFIGDYNAMICOBJECTS, and CONFIGSMP. 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 listslock across the bitmap RMW and the permissions clear (and inlining the objlist traversal that previously took the lock itself).

Zephyr's IPv6 forwarding path re-sent routed unicast packets without ever decrementing the IPv6 hop limit. Both routing branches of ipv6routepacket() (subsys/net/ip) were affected: the explicit-route path (netroutepacket()) and the on-link cross-interface path (netroutepacketif()). Each set the packet forwarding flag and called netsenddata() with the hop limit untouched and no expiry check.

Per RFC 8200 the hop-limit decrement is the mechanism that bounds packet lifetime and terminates routing loops; without it, a device acting as an IPv6 router relays looping packets indefinitely. An on-path attacker who can induce or exploit a transient L3 loop turns it into a permanent forwarding storm, causing CPU/bandwidth resource exhaustion (availability DoS) on the forwarder and adjacent links; path-discovery and loop diagnostics that rely on hop-limit expiry are also defeated.

Affected configurations. In every affected release the forwarding path is reached via CONFIGNETROUTE (enabled by default when CONFIGNETIPV6NBRCACHE is set), together with CONFIGNETROUTING for cross-interface routing. Note that CONFIGNETIPV6FORWARDING and CONFIGNETIPV4FORWARDING — which appear in the fix and in this advisory's evidence notes — were introduced after v4.4.0, when the routing options were split and renamed; they do not exist in any affected release. When auditing a v4.4.1-or-earlier configuration, look for CONFIGNETROUTE and CONFIGNETROUTING.

IPv4 is not affected in any release. The IPv4 forwarding path (netrouteipv4packet() in routeipv4.c) was added after v4.4.0 and has never shipped in a release. Its TTL decrement and IPv4 header-checksum recomputation landed on main as part of the same fix, so the evidence notes below discuss it, but no released version is reachable by way of IPv4.

Affected releases are v1.8.0 through v4.4.1: v1.8.0 introduced netroutepacket() and v2.2.0 added netroutepacketif(), and neither decremented the hop limit. v4.3.1 carries the explicit-route fix but not the on-link one, so it is affected as well. Fixed on main by 7d8f1afa7345 (explicit-route path) and 589eadc74efa (on-link path).

Zephyr's IP socket recvmsg() implementation (subsys/net/lib/sockets/socketsinet.c, insertpktinfo()) validated the user-supplied ancillary (msgcontrol) buffer using only the payload length (msg->msgcontrollen < pktinfolen) 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 IPPKTINFO 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 CONFIGUSERSPACE the recvmsg verifier allocates a kernel-heap copy of the control buffer sized to msgcontrollen 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 IPPKTINFO/IPV6RECVPKTINFO (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 ipiaddr) is influenced by the received packet.

The fix makes the capacity check use NETCMSGSPACE(pktinfolen) (aligned header + aligned data) and returns -ENOMEM when the buffer is too small. Affected: v3.6.0 through v4.4.0.

Zephyr's native TCP stack iterates the global connection list in nettcpforeach() (subsys/net/ip/tcp.c) using the SYSSLISTFOREACHCONTAINERSAFE macro, which caches a pointer to the next list node. Prior to this fix the function released tcplock while invoking the per-connection callback and re-acquired it afterwards.

During that window a concurrent tcpconnrelease(), running on the dedicated TCP work-queue thread when a connection's reference count drops to zero (e.g. a remote peer closing or resetting the connection), can remove and kmemslabfree() the cached next connection. When the iterator advances it dereferences the freed (and possibly reallocated) slab memory — a use-after-free that can crash the system (denial of service) and, if the slot has been reused, cause the callback to operate on an attacker-influenced object (potential information disclosure or further fault).

nettcpforeach() is reached in production via the net conn network shell command and via nettcpcloseallforiface() on interface-down; the freeing side is driven by ordinary TCP traffic.

The fix moves the connection/context teardown in tcpconnrelease() inside the tcplock critical section and keeps tcplock held across the callback in nettcpforeach(). The defect was introduced with the modern (TCP2) stack in 2020 and affects releases up to and including v4.4.0.

In Zephyr's native IPv4 stack, icmpv4handleechorequest() in subsys/net/ip/icmpv4.c builds an echo-reply packet (reply), hands it to nettrysenddata(), and then, on success, calls netstatsupdateicmpsent(netpktiface(reply)). nettrysenddata() transfers ownership of reply to the TX path (netiftryqueuetx -> netiftx -> L2/driver send, or the asynchronous netiftxthread), which can unref it to refcount 0 and return the struct netpkt to its slab (netpktunref -> kmemslabfree) before the stats line runs. netcore.c documents this exact contract ('the pkt might contain garbage already ... do not use pkt after that call').

The post-send netpktiface(reply) therefore reads reply->iface out of a freed (and possibly already reallocated) netpkt, a use-after-free read; with CONFIGNETSTATISTICSPERINTERFACE the stats macro additionally increments a counter through that value, i.e. a dereference/write through a stale or recycled-slot pointer.

The path is reached unauthenticated by any remote host that pings the device (neticmpv4input -> neticmpcallipv4handlers -> icmpv4handleechorequest) and is gated on CONFIGNETSTATISTICSICMP. Impact is a probabilistic read of recycled packet memory plus a possible wild-pointer write under a timing race, leading most likely to corrupted interface statistics or a remotely triggerable crash (DoS).

The defect was introduced in 2019 (v1.14) and is present through v4.4.0. The companion change in neticmpv4senderror() is not a use-after-free because it reads netpktiface(orig), the caller-owned received packet, which stays alive across the send. The fix caches the interface pointer from the live received packet before sending and uses it for the post-send stats updates.

The MCTP-over-I2C+GPIO target binding in Zephyr (subsys/pmci/mctp/mctpi2cgpiotarget.c) processes pseudo-register writes from an I2C bus master byte-by-byte in mctpi2cgpiotargetwritereceived() without validating the order or the receive buffer. In the affected versions the MCTPI2CGPIORXMSGADDR (data) handler dereferences and writes through b->rxpkt 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 mctppktbuf 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.

A bitwise shift vulnerability in Zephyr's PTP subsystem allows a remote attacker to cause undefined behavior and potential system crashes. An attacker sends a crafted PTPMSGMANAGEMENT message to set an unvalidated negative logannounceinterval value in the port's data set. When a subsequent PTPMSGANNOUNCE message is processed, porttimersettimeoutrandom computes a timeout as NSECPERSEC >> -logseconds; if the attacker-supplied value is sufficiently negative (e.g., -127), the shift amount exceeds the 64-bit integer width, triggering undefined behavior in C. This can cause a system crash via a compiler-generated illegal instruction trap on some architectures, or produce an erroneous zero timeout leading to resource starvation loops or other logical errors.

An integer underflow in btmeshsolrecv() in the Bluetooth Mesh solicitation handling (subsys/bluetooth/mesh/solicitation.c) leads to an out-of-bounds write. When CONFIGBTMESHODPRIVPROXYSRV is enabled, the function parses solicitation PDUs from raw BLE advertising payloads. The AD parsing loop reads an attacker-controlled length byte (reportedlen) and computes reportedlen - 3 without checking that reportedlen >= 3. When reportedlen is less than 3, the subtraction is performed in signed int arithmetic and yields a negative value that bypasses the length guard and is then implicitly converted to a very large sizet when passed to netbufsimplepullmem(). In builds without assertions, this wraps the buffer length and advances the data pointer far out of bounds, so subsequent reads dereference invalid memory. A nearby BLE device can trigger this with a non-connectable advertisement carrying a UUID16 AD structure and a crafted length byte, with no pairing or prior association required, potentially leading to denial of service or arbitrary code execution.

A potential out-of-bounds write/read exists in the TLS socket connect path of the network sockets subsystem (subsys/net/lib/sockets/socketstls.c). When the TLS session cache is enabled, tlssessionstore() and tlssessionrestore() memcpy the caller-supplied address into a fixed-size buffer using the caller-controlled addrlen value without validating it against the destination size. struct netsockaddr is an opaque type, so an application can pass an addrlen larger than sizeof(struct netsockaddr) (for example 128 bytes into a 24-byte stack buffer), causing the memcpy to read and write past the end of the address memory used by the TLS session cache. This out-of-bounds write can lead to a crash and denial of service, and potentially to arbitrary code execution.

The SocketCAN implementation validates the length of a user-provided buffer containing a socketcanframe object using only a NETASSERT statement in zcansendtoctx() before dereferencing it in socketcantocanframe(). In production builds where assertions are disabled, a userspace application that controls the length passed to a sendto syscall can supply an incomplete or truncated frame, causing socketcantocanframe() to dereference fields beyond the end of the buffer. This results in an out-of-bounds read that can cause denial-of-service crashes or, because the parsed frame contents are transmitted on the network, leak adjacent memory.

btsdpparseattribute() in subsys/bluetooth/host/classic/sdp.c validated only that the SDP record buffer held the type-marker byte plus the 2-byte attribute ID (a check of buf->len < 3) but then read a fourth byte, the data-element descriptor (type), via netbufsimplepullu8(). Because netbufsimplepullu8() dereferences buf->data[0] before its only bounds guard (an ASSERTNOMSG that compiles out when CONFIGASSERT is disabled, the production default), a record of exactly three bytes (0x09 followed by a 2-byte attribute ID) causes a one-byte read past the end of the logical buffer. The parser is reachable from inbound, remote-controlled data: a Bluetooth BR/EDR peer acting as an SDP server returns discovery-response records that are stored verbatim in the client receive buffer and parsed via the public btsdpgetattr()/btsdphasattr()/btsdprecordparse() helpers. The over-read is bounded to a single byte that is used only as an internal length selector and is never leaked to the attacker; subsequent length checks then reject the malformed record. Realistic impact is therefore limited to an edge-case denial of service (a fault only if the record ends exactly at a mapped-memory boundary, or a deterministic assert panic when CONFIGASSERT=y). Affects Zephyr v4.3.0 and v4.4.0; fixed by adding sizeof(type) to the length check.

parseipv4() in subsys/net/ip/utils.c (reached via netipaddrparse() for strings of the form "a.b.c.d:port") copies the port substring into a fixed 17-byte stack buffer (char ipaddr[NETIPV4ADDRLEN + 1]) using a length of strlen - end - 1, where strlen 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 (zsockgetaddrinfo / 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 parseipv6() retains the same unbounded copy at this commit and remains a separate, still-reachable instance of the defect.

Zephyr's dynamic kernel-object tracking (kernel/userspace/userspace.c, formerly kernel/userspace.c) maintains a doubly-linked list (objlist) of dynamically allocated kernel objects. Iteration over this list in kobjectwordlistforeach() was performed under listslock using the SAFE iterator (which caches the next node), but list removal and freeing of nodes was performed under different, disjoint spinlocks: objfreelock in kobjectfree() and objlock in unrefcheck(). On an SMP system, while one CPU iterated objlist under listslock, another CPU could unlink and kfree() the dynobj node that the iterator had cached as its next pointer, causing the iterator to dereference freed kernel memory (use-after-free / dangling list traversal). All of the racing operations are reachable from unprivileged user-mode threads via system calls: kobjectalloc/kobjectallocsize and kobjectrelease drive removals through unrefcheck() (under objlock), while kthreadabort and thread creation drive the iteration through kthreadpermsallclear()/kthreadpermsinherit() (under listslock). A deprivileged user thread on a CONFIGSMP + CONFIGUSERSPACE build can therefore corrupt the kernel's object-tracking structures across the userspace security boundary, yielding kernel memory corruption (potential privilege escalation) or a kernel crash (denial of service). The fix removes objfreelock and serializes every objlist modification under listslock, including holding it across find+remove in kobjectfree() and around unrefcheck() in kthreadpermsclear(). Affects CONFIGSMP+CONFIGUSERSPACE+CONFIGDYNAMICOBJECTS configurations; the defect dates to the 2019 spinlockification (commit 8a3d57b6cc6, first released in v1.14.0) and shipped through v4.4.0.

In Zephyr's experimental USB host stack (CONFIGUSBHOSTSTACK), usbhdevicedisconnect() (subsys/usb/host/usbhdevice.c) freed the root usbdevice slab object without clearing the cached pointer ctx->root. The bus removal handler devremovedhandler() (subsys/usb/host/usbhcore.c) decides what to tear down solely from ctx->root, checking only that it is non-NULL.

Because UHC controller drivers (e.g. uhcmax3421e, uhcmcuxcommon) synthesize UHCEVTDEVREMOVED directly from physical bus line state with no debounce or state guard, an attacker with physical USB access (or a rogue device that bounces its connection) can deliver a second device-removed event after a root device disconnect. The handler then re-enters usbhdevicedisconnect() with the dangling pointer, locking a mutex inside the freed object (use-after-free), removing the freed node from the device list, and calling kmemslabfree() on the already-freed block (double-free). If the slab block has been reissued to a newly attached device in between, this corrupts a live object.

Impact is denial of service (crash) and memory corruption; the attack vector is physical/local. The flaw was introduced in v4.4.0 by the connect/disconnect refactor and is fixed by clearing ctx->root in usbhdevicedisconnect() before freeing.

In Zephyr's WireGuard subsystem (subsys/net/lib/wireguard), wgprocessdatamessage() in wgcrypto.c linearizes an inbound transport-data payload into a fixed pool buffer of CONFIGWIREGUARDBUFLEN bytes before decryption. The call netbuflinearize(buf->data, datalen, pkt->buffer, ..., datalen) passed the attacker-derived datalen as both the destination capacity and the copy length, defeating the function's internal len = min(len, dstlen) bound. datalen is derived from the received UDP datagram length and is only lower-bounded by wgctrlrecv() (no upper bound). When datalen exceeds CONFIGWIREGUARDBUFLEN — e.g. when the buffer length is lowered below the link MTU, on links with MTU above the buffer size, or via reassembled IPv4/IPv6 fragments that exceed it — the underlying memcpy writes past the end of the pool buffer, an out-of-bounds write (CWE-787). The overflow occurs before the Poly1305 authentication check, so it requires only a valid receiver session index rather than a valid authenticator, and is reachable by a malicious or compromised peer (or an on-path attacker driving an established session) over the network, yielding remote memory corruption and at minimum a reliable denial of service. The defect was present in the WireGuard implementation shipped in Zephyr 4.4.0. The fix adds an explicit datalen > CONFIGWIREGUARDBUFLEN rejection and corrects the linearize call to pass netbufmaxlen(buf) as the destination capacity.

btisorecv() in subsys/bluetooth/host/iso.c pulled the ISO SDU header (4 bytes) or, when the timestamp flag is set, the timestamped SDU header (8 bytes) from the inbound HCI ISO Data buffer via netbufpullmem() without first checking buf->len. The upstream hciiso() handler enforces buf->len == the controller-declared ISO DataLoad length, so a malicious or buggy controller / adjacent BLE peer on an established CIS/BIS can present a first-fragment (BTISOSTART) or single (BTISOSINGLE) PDU shorter than the SDU header. Because netbufsimplepullmem only guards length with ASSERTNOMSG (compiled out when CONFIGASSERT is disabled, the production default), the pull underflows buf->len (uint16t, e.g. 0 - 8 = 0xFFF8) and advances buf->data past valid data: the subsequent reads of hdr->slen and hdr->sn are out-of-bounds reads of adjacent pool memory. For the multi-fragment (START) case the corrupted buffer is retained as iso->rx, and a following CONT/END fragment's netbuftailroom() guard underflows to a near-SIZEMAX value, defeating the bounds check and causing netbufaddmem() to memcpy attacker-supplied fragment data far past the RX pool buffer (out-of-bounds write). The flaw affects ISO receive builds (CONFIGBTISORX, selected by the default-off LE Audio options BTISOPERIPHERAL/BTISOCENTRAL/BTISOSYNCRECEIVER) and has existed since the ISO subsystem was introduced (v2.6.0) through v4.4.0. The fix adds explicit buf->len < sizeof(tshdr) and buf->len < sizeof(hdr) checks that drop the buffer before pulling.