https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 19:30:10 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-18417 <p>The native BSD-socket layer recorded a pending asynchronous socket error by type-punning it into struct net_context&#39;s void user_data field (ctx-&gt;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 .</p> <p>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&#39;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()&#39;s read-modify-write of socket_data, k_fifo_cancel_wait(&amp;parent-&gt;recv_q)) — the crash described in the fix&#39;s commit message. v4.3.1 and v4.4.x carry a later change clearing conn-&gt;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 rac…</p> <p>The native BSD-socket layer recorded a pending asynchronous socket error by type-punning it into struct net_context&#39;s void user_data field (ctx-&gt;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 .</p> <p>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&#39;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()&#39;s read-modify-write of socket_data, k_fifo_cancel_wait(&amp;parent-&gt;recv_q)) — the crash described in the fix&#39;s commit message. v4.3.1 and v4.4.x carry a later change clearing conn-&gt;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 rac…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-18417