### [CVE-2025-38154](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-38154)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=3627605de498639a3c586c8684d12c89cba11073%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=4959ffc65a0e94f8acaac20deac49f89e6ded52d%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=4b4647add7d3c8530493f7247d11e257ee425bf0%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=5eabdf17fed2ad41b836bb4055ec36d95e512c50%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=6.10%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=e946428439a0d2079959f5603256ac51b6047017%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)

### Description

In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Avoid using sk_socket after free when sendingThe sk->sk_socket is not locked or referenced in backlog thread, andduring the call to skb_send_sock(), there is a race condition withthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)will be affected.Race conditions:'''CPU0                               CPU1backlog::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 insock_map_close() if psock is held, we simply increase the psockreference count to avoid race conditions.With this patch, if the backlog thread is running, sock_map_close() willwait for the backlog thread to complete and cancel all pending work.If no backlog running, any pending work that hasn't started by then willfail when invoked by sk_psock_get(), as the psock reference count havebeen zeroed, and sk_psock_drop() will cancel all jobs viacancel_delayed_work_sync().In summary, we require synchronization to coordinate the backlog threadand close() thread.The panic I catched:'''Workqueue: events sk_psock_backlogRIP: 0010:sock_sendmsg+0x21d/0x440RAX: 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...'''

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/w4zu/Debian_security