Description

The native BSD-socket layer recorded a pending asynchronous socket error by type-punning it into struct net_context's void user_data field (ctx->user_data = INT_TO_POINTER(-status) in zsock_accepted_cb(), zsock_received_cb(), zsock_connected_cb() and zsock_close_ctx() in subsys/net/lib/sockets/sockets_inet.c), reading it back with POINTER_TO_INT(). That same field is owned by the network stack for listening TCP contexts: net_tcp_accept() 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 net_context . When the network interface carrying a listening TCP socket goes down, close_tcp_conn() in subsys/net/ip/tcp.c invokes the accept callback with -ENETDOWN and the context's user_data. In v4.3.0 the callback was not disarmed afterwards, so a second interface-down event forwarded the previously stored errno to zsock_accepted_cb(), which dereferenced it as the parent context and performed several stores through it (sock_set_error()'s read-modify-write of socket_data, k_fifo_cancel_wait(&parent->recv_q)) — the crash described in the fix's commit message. v4.3.1 and v4.4.x carry a later change clearing conn->accept_cb 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 k_fifo_put(&parent->accept_q, ...), and by getsockopt(SO_ERROR), 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 net_context.sock_error field and converts every producer and consumer to sock_set_error()/sock_get_error(), leaving user_data untouched. As a side effect it also stops getsockopt(SO_ERROR) — which is evaluated unconditionally — from returning the kernel address held in user_data to a userspace application.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-29T00:17:04.207Z",
  "pubdate": "2026-09-29T00:17:04.207Z",
  "executiveSummary": "A memory corruption vulnerability exists in the Zephyr RTOS native BSD-socket layer due to improper type-punning of error codes within the struct net_context structure.\nThe vulnerability occurs when a pending asynchronous socket error is stored in the user_data field, which the TCP stack concurrently treats as a pointer to a parent context.\nAffected products include Zephyr RTOS versions v4.3.0, v4.3.1, and v4.4.x.\nThe flaw allows for a kernel-level denial of service (system crash or reset) by triggering a wild-pointer dereference.\nThe attack vector involves manipulating network interface states, such as forcing repeated link-down events, which can be achieved by an adjacent attacker or someone with physical access.\nWhile the primary impact is limited to device instability, the vulnerability highlights a critical design flaw in how socket errors are managed, allowing the kernel to perform unauthorized read-modify-write operations on invalid memory addresses.",
  "technicalDetails": "The root cause of this vulnerability is the overloading of the struct net_context user_data field, which serves dual purposes: storing a pointer to a parent context for listening TCP sockets and acting as a temporary storage for asynchronous socket error codes (errno values) cast to pointers via INT_TO_POINTER().\nIn subsys/net/lib/sockets/sockets_inet.c, functions such as zsock_accepted_cb(), zsock_received_cb(), zsock_connected_cb(), and zsock_close_ctx() inject small integer errno values into the user_data field. The TCP core, specifically net_tcp_accept(), concurrently assumes this field holds a valid struct net_context pointer. When a failed accept occurs, the field is populated with a small integer instead of a valid structure address.\nOn Zephyr v4.3.0, a race condition allows this poisoned state to persist. When a network interface enters a down state, close_tcp_conn() in subsys/net/ip/tcp.c triggers the accept callback with -ENETDOWN. Because the callback mechanism was not disarmed in v4.3.0, subsequent interface-down events cause the stack to interpret the stored errno as a legitimate struct net_context pointer.\nThe exploitation flow proceeds as follows: 1) The attacker forces repeated interface link-down events, 2) The network stack executes callback functions using the poisoned user_data field, 3) The kernel performs operations such as sock_set_error() or k_fifo_cancel_wait() using this illegal address as the base pointer for dereferencing. This results in a kernel fatal error due to the invalid memory access.\nWhile v4.3.1 and v4.4.x mitigate the persistent callback path by clearing conn->accept_cb, the vulnerability remains reachable through narrower windows, specifically during concurrent handshake completions or via the getsockopt(SO_ERROR) system call. The latter reads the user_data field unconditionally, potentially exposing the kernel-held address or triggering further logic errors.\nThe impact is limited to a kernel-level denial of service rather than arbitrary code execution, as the faulting address and stored data are fixed constants derived from standard errno definitions. However, the use of these constants to perform write operations creates a critical reliability issue for network-dependent devices."
}