CVE-2025-38154 — bpf, sockmap: Avoid using sk_socket after free when sending

Affected: Linux

In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Avoid using sk_socket after free when sending

The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.

Race conditions: ''' CPU0 CPU1

backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''

Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if t…

Most recent entries from all

CVE-2025-38154 — bpf, sockmap: Avoid using sk_socket after free when sending