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.

The MAX32xxx USB device controller driver (drivers/usb/udc/udcmax32.c, compatible adimax32usbhs) dereferenced an endpoint buffer in its OUT and IN transfer-completion handlers without checking it for NULL. udceventxferoutdone() called netbufadd(buf, eprequest->actlen) immediately after buf = udcbufget(epcfg), where udcbufget() returns NULL when the endpoint FIFO is empty.

A transfer-completion event is queued from interrupt context and processed asynchronously by the driver thread; between queuing and processing, the endpoint FIFO can be drained by host-controlled control flow — in particular udcsetupreceived() drains the EP0 OUT/IN FIFOs whenever a new SETUP packet arrives, and dequeue/disable/purge paths drain it likewise.

A USB host that aborts an in-flight EP0 control transfer with a new SETUP packet (legal USB behavior) can therefore cause a stale XFEROUTDONE event to be processed against an empty FIFO, producing netbufadd(NULL, ...), a near-NULL pointer dereference that faults and crashes the device. No authentication is required; the attacker is the USB host the device is connected to (physical bus access). Impact is denial of service (device crash).

The defect was introduced when the MAX32 UDC driver was added and shipped in Zephyr v4.4.0. The fix adds NULL-buffer checks that return early with UDCEVTERROR/-ENOBUFS in both the OUT-done and IN-done handlers.

The asynchronous SNTP client in Zephyr (subsys/net/lib/sntp/sntp.c, sntpcloseasync) closed the UDP socket file descriptor directly from the calling thread immediately after detaching it from the network socket service, without synchronizing with the socket-service poll thread.

The socket service thread polls each socket via zvfspoll, which (in zsockpollpreparectx) registers a kpollevent pointing into the socket's netcontext (&ctx->recvq) and then blocks in kpoll without holding a reference or lock. netcontext objects are allocated from a fixed pool (contexts[CONFIGNETMAXCONTEXTS]) and reused after close.

When sntpcloseasync is invoked from a different thread than the poll thread (in the in-tree consumer subsys/net/lib/config/initclocksntp.c, the SNTP timeout handler runs on the system workqueue while the socket service thread is blocked in poll on the same fd), the close frees and may reuse the netcontext while the poll thread still has a poller node linked into the freed object, resulting in a use-after-free / object confusion of kernel poll structures.

The SNTP timeout path is the normal no-response failure mode, so a network peer or off-path attacker who drops or delays the SNTP/NTP response can drive the racing close repeatedly (and periodically with NETCONFIGSNTPINITRESYNC). The most likely consequence is a crash of the networking thread (denial of service), with potential memory corruption when the freed context slot is reallocated.

The fix defers the close to the socket service thread itself via netsocketserviceclose (NETSOCKETSERVICECLOSESOCKETS), so the same thread that polls performs the close, eliminating the race. Affected releases: v4.2.0 through v4.4.0.

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.