Bug 2376056 (CVE-2025-38154) - CVE-2025-38154 kernel: Linux kernel: Use-after-free in BPF sockmap can lead to denial of service and privilege escalation
Summary: CVE-2025-38154 kernel: Linux kernel: Use-after-free in BPF sockmap can lead t...
Keywords:
Status: NEW
Alias: CVE-2025-38154
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-07-03 09:02 UTC by OSIDB Bzimport
Modified: 2026-04-01 00:45 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2026:3520 0 None None None 2026-03-02 11:41:17 UTC
Red Hat Product Errata RHSA-2026:5690 0 None None None 2026-03-25 00:20:29 UTC
Red Hat Product Errata RHSA-2026:5813 0 None None None 2026-03-25 14:30:52 UTC
Red Hat Product Errata RHSA-2026:6310 0 None None None 2026-04-01 00:45:09 UTC

Description OSIDB Bzimport 2025-07-03 09:02:43 UTC
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
...
'''

Comment 1 Avinash Hanwate 2025-07-03 18:15:10 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025070337-CVE-2025-38154-8353@gregkh/T

Comment 4 errata-xmlrpc 2026-03-02 11:41:16 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.6 Extended Update Support

Via RHSA-2026:3520 https://access.redhat.com/errata/RHSA-2026:3520

Comment 5 errata-xmlrpc 2026-03-25 00:20:28 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions

Via RHSA-2026:5690 https://access.redhat.com/errata/RHSA-2026:5690

Comment 6 errata-xmlrpc 2026-03-25 14:30:50 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions

Via RHSA-2026:5813 https://access.redhat.com/errata/RHSA-2026:5813

Comment 7 errata-xmlrpc 2026-04-01 00:45:08 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.4 Extended Update Support

Via RHSA-2026:6310 https://access.redhat.com/errata/RHSA-2026:6310


Note You need to log in before you can comment on or make changes to this bug.