Zephyr Project up to 4.4.1 BSD Socket Layer sockets_inet.c user_data null pointer dereference

Summaryinfo

A vulnerability described as critical has been identified in Zephyr Project Zephyr up to 4.4.1. The impacted element is the function zsock_accepted_cb/zsock_received_cb/zsock_connected_cb/zsock_close_ctx of the file subsys/net/lib/sockets/sockets_inet.c of the component BSD Socket Layer. Executing a manipulation of the argument user_data can lead to null pointer dereference. This vulnerability is registered as CVE-2026-18417. It is possible to launch the attack remotely. No exploit is available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability classified as critical was found in Zephyr Project Zephyr up to 4.4.1. This vulnerability affects the function zsock_accepted_cb/zsock_received_cb/zsock_connected_cb/zsock_close_ctx of the file subsys/net/lib/sockets/sockets_inet.c of the component BSD Socket Layer. The manipulation of the argument user_data with an unknown input leads to a null pointer dereference vulnerability. The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. As an impact it is known to affect availability. CVE summarizes:

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.

The advisory is shared for download at github.com. This vulnerability was named CVE-2026-18417 since 07/30/2026. The exploitation appears to be easy. The attack can be initiated remotely. No form of authentication is required for a successful exploitation. There are known technical details, but no exploit is available.

Upgrading to version 4.4.2 eliminates this vulnerability. Applying the patch ef370a57d07637aaee8cec7b0bcebf4002ac8f54/269cb8823d3 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2026-88573). Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• Zephyr Project

Name

• Zephyr

Version

• 4.4.0
• 4.4.1

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion