In the Synopsys DesignWare I2C driver (drivers/i2c/i2cdw.c) operating in target/slave mode, the rxfull interrupt handler gates the writerequested() callback on dw->state != CMDSEND, and dw->state is only reset to READY on a STOP interrupt. The STARTDET interrupt, whose handler in i2cdwslavereadclearintrbits() would reset the state on every (re)START, was never added to the enabled interrupt mask in i2cdwslaveregister(), so that recovery path was dead code.

As a result, if the STOP interrupt is lost (bus glitch/reset, or a concurrent master driving STOP) or the bus master issues a legal WRITE-repeated-START-WRITE sequence with the same direction, the driver remains in CMDSEND permanently and never invokes writerequested() again for the life of the target.

An I2C master on the same physical bus can deliberately trigger this, causing the I2C target function to malfunction for all subsequent write transactions and desynchronizing consumer framing state (e.g. MCTP-over-I2C), a recoverable-by-reset denial of service of the target peripheral.

The fix unmasks STARTDET so the state is reset at every bus (re)START. Impact is availability-only over a local board-level bus; no memory corruption results in the in-tree consumer, whose per-byte buffer write is independently bounds-checked.

Zephyr's BSD-sockets getaddrinfo() implementation (subsys/net/lib/sockets/getaddrinfo.c) passes a pointer to a stack-allocated state object (struct getaddrinfostate aistate) as the userdata of an asynchronous DNS resolver query. The socket layer waits on a semaphore with a timeout deliberately set slightly longer than the resolver's own per-query timeout. When that semaphore wait nonetheless times out (-EAGAIN) - which can occur when the resolver's timeout work is delayed by workqueue contention, or in the documented multi-retry configuration where CONFIGNETSOCKETSDNSTIMEOUT exceeds CONFIGNETSOCKETSDNSBACKOFFINTERVAL - the pre-fix code retries the query (goto again) without cancelling the previous one and without resetting the semaphore.

The previous query slot remains active in the resolver with its callback and the stack pointer as userdata, and aistate->dnsid is overwritten so the stale query can no longer be cancelled. A subsequent DNS response delivered over UDP and matched by its 16-bit transaction id (in dispatchercb()/dnsread()), or the resolver's own delayed query-timeout work, then invokes dnsresolvecb() against the now out-of-scope stack frame, writing through the stale pointer (state->status, state->idx, state->aiarr[], and ksemgive()).

Because the triggering response is network-delivered and its 16-bit id is spoofable/replayable by an on- or off-path attacker, this is a network-influenceable use-after-return that can corrupt reused stack memory, leading to crashes/denial of service or memory corruption.

The fix cancels the timed-out query by name and type before retrying and resets the local semaphore, eliminating the stale callback path. Affected: Zephyr v4.0.0 through v4.4.0.

Zephyr's HTTP server (subsys/net/lib/http) provides a static-filesystem resource type (HTTPRESOURCETYPESTATICFS, available when CONFIGFILESYSTEM is enabled) that serves files from a configured root directory. Before this fix, both the HTTP/1 and HTTP/2 front-ends placed the raw, attacker-controlled request path into client->urlbuffer (assembled in onurl() for HTTP/1 and copied verbatim from the :path pseudo-header for HTTP/2) without resolving ./.. segments. The static-FS handler then built the on-disk filename by directly concatenating the configured root with that raw URL (snprintk(fname, ..., "%s%s", staticfsdetail->fspath, client->urlbuffer) at httpserverhttp1.c:603 and httpserverhttp2.c:490) and opened it with fsopen(fname, FSOREAD). Because the handler is reached via wildcard/leading-dir (fnmatch FNMLEADINGDIR) or fallback resource matching, a request such as GET /<prefix>/../../<file> is dispatched to the handler and, after the underlying filesystem (e.g. LittleFS/FAT) resolves the .. segments, escapes the configured web root, letting an unauthenticated remote client read arbitrary readable files on the mounted volume (information disclosure). The HTTP server requires no TLS or authentication to reach this path. The fix adds httpserverremovedotsegments(), which canonicalizes the path portion of the URL before resource lookup in both protocol handlers, neutralizing the traversal. Affects releases v4.0.0 through v4.4.0 for deployments that register a static-filesystem resource.

The nRF70 Wi-Fi driver's power-save event handler nrfwifieventprocgetpowersaveinfo() in drivers/wifi/nrfwifi/src/wifimgmt.c copied TWT (Target Wake Time) flow entries from an nrfwifiumaceventpowersaveinfo event into the fixed-size twtflows[WIFIMAXTWTFLOWS] (8-element) array of a caller-supplied struct wifipsconfig, looping over event-provided numtwtflows without validating it against WIFIMAXTWTFLOWS or checking eventlen. When numtwtflows exceeds 8, the handler writes past the destination array (which is typically on the caller's stack, e.g. the wifi ps shell command) -- an out-of-bounds write of ~40-byte TWT entries -- and reads twtflowinfo[i] past the event buffer. The event is delivered by the nRF70 co-processor firmware in response to a host-initiated power-save GET, so reaching the overflow requires the firmware to emit a malformed or out-of-range event; the trust boundary is host-to-trusted-coprocessor rather than a direct remote-AP write, with over-the-air influence on the flow count being indirect and bounded by the 3-bit TWT flow-id space. Affected: builds with CONFIGNRF70STAMODE on releases through v4.4.0. The fix rejects events with numtwtflows > WIFIMAXTWTFLOWS or with eventlen shorter than the claimed entries, and adds a NULL check on the caller buffer.

Zephyr's Bluetooth Classic Hands-Free Profile (HFP) Hands-Free role parser (subsys/bluetooth/host/classic/hfphf.c) contains an out-of-bounds write. During Service Level Connection setup the HF sends AT+CIND=? and parses the AG's +CIND: response in cindhandle(), which assigns a per-entry counter index and calls cindhandlevalues() for each list element. cindhandlevalues() then wrote hf->indtable[index] = i without verifying that index is within the 20-element int8t indtable[] array of struct bthfphf. Because the parser places no cap on the number of +CIND: list entries, a remote Attendant Gateway (a malicious, compromised, or spoofed peer the device connects to over Bluetooth) can send a response with more than 20 recognized indicator entries and drive index arbitrarily large, writing a small attacker-positioned value past the array into adjacent struct fields (feature masks, SDP/version state, the calls[] array, work/atomic bookkeeping) and potentially beyond the static connection pool slot. This yields memory corruption and at least denial of service of the Bluetooth host, triggered by a single malformed AT response with no user interaction. The sibling consumer agindicatorhandlevalues() already performed the equivalent bounds check; this commit adds the same index >= ARRAYSIZE(hf->indtable) guard to close the gap. Affects builds with CONFIGBTHFPHF enabled; introduced with the original HFP HF CIND parser (~v1.7) and present through v4.4.0.