CVE-2025-38154
Analyzed Analyzed - Analysis Complete
BaseFortify

Publication date: 2025-07-03

Last updated on: 2025-12-18

Assigner: kernel.org

Description
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 the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work. If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync(). In summary, we require synchronization to coordinate the backlog thread and close() thread. The panic I catched: ''' 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 ... '''
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-03
Last Modified
2025-12-18
Generated
2026-05-07
AI Q&A
2025-07-03
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38154
Affected Vendors & Products
Showing 14 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15.162 (inc) to 5.15.186 (exc)
linux linux_kernel From 6.1.95 (inc) to 6.1.142 (exc)
linux linux_kernel From 6.6.35 (inc) to 6.6.94 (exc)
linux linux_kernel From 6.9.6 (inc) to 6.10 (exc)
linux linux_kernel From 6.10.1 (inc) to 6.12.34 (exc)
linux linux_kernel From 6.13 (inc) to 6.15.3 (exc)
linux linux_kernel 6.10
linux linux_kernel 6.10
linux linux_kernel 6.10
linux linux_kernel 6.10
linux linux_kernel 6.10
linux linux_kernel 6.10
linux linux_kernel 6.10
debian debian_linux 11.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a race condition in the Linux kernel's handling of socket buffers (bpf, sockmap). Specifically, the sk_socket pointer is used after it has been freed during concurrent operations between sending data and closing sockets. This can cause a kernel panic due to accessing freed memory. The issue affects all socket types (tcp/udp/unix/vsock) and arises because the socket is not properly locked or referenced in the backlog thread, leading to unsafe concurrent access. The fix involves increasing the reference count and synchronizing the backlog and close threads to avoid use-after-free conditions.


How can this vulnerability impact me? :

This vulnerability can cause a kernel panic, leading to system crashes or instability when socket operations occur concurrently with socket closure. This can result in denial of service (DoS) conditions on affected systems, potentially disrupting network communications and services relying on the Linux kernel's socket handling.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart