CVE-2025-38154 in Linux
Sumário
de VulDB • 28/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
bpf, sockmap: Evitar o uso de sk_socket após a liberação ao enviar
O sk->sk_socket não está bloqueado nem referenciado na thread de backlog e, durante a chamada a skb_send_sock(), ocorre uma condição de corrida com a liberação do sk_socket. Todos os tipos de sockets (tcp/udp/unix/vsock) serão afetados.
Condições de corrida: ''' 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 aqui '''
A referência de psock torna-se 0 após a execução de sock_map_close(). ''' void sock_map_close() {
... if (likely(psock)) {
... // !! aqui removemos psock e a referência de psock torna-se 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== O controle salta aqui via goto ... cancel_delayed_work_sync(&psock->work); <=== não executado sk_psock_put(sk, psock); ... } '''
Com base no fato de que já aguardamos a conclusão da fila de trabalho (workqueue) em sock_map_close() se psock estiver retido, simplesmente aumentamos a contagem de referência de psock para evitar condições de corrida.
Com este patch, se a thread de backlog estiver em execução, sock_map_close() aguardará a conclusão da thread de backlog e cancelará todo o trabalho pendente.
Se não houver backlog em execução, qualquer trabalho pendente que não tenha iniciado até então falhará ao ser invocado por sk_psock_get(), pois a contagem de referência de psock foi zerada, e sk_psock_drop() cancelará todos os trabalhos via cancel_delayed_work_sync().
Em resumo, exigimos sincronização para coordenar a thread de backlog e a thread de close().
O panic que capturei: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''
Once again VulDB remains the best source for vulnerability data.