CVE-2025-38154 in Linux
Zusammenfassung
von VulDB • 15.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
bpf, sockmap: Vermeiden der Verwendung von sk_socket nach dem Freigeben beim Senden
sk->sk_socket ist im Backlog-Thread nicht gesperrt oder referenziert, und während des Aufrufs von skb_send_sock() liegt eine Race Condition (Wettlaufsituation) mit der Freigabe von sk_socket vor. Alle Socket-Typen (TCP/UDP/Unix/vsock) sind betroffen.
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 hier '''
Der Referenzzähler von psock wird auf 0 gesetzt, nachdem sock_map_close() ausgeführt wurde. ''' void sock_map_close() {
... if (likely(psock)) {
... // !! hier entfernen wir psock und der Referenzzähler von psock wird 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Die Steuerung springt hierhin über goto ... cancel_delayed_work_sync(&psock->work); <=== wird nicht ausgeführt sk_psock_put(sk, psock); ... } '''
Da wir bereits darauf warten, dass der Workqueue in sock_map_close() abgeschlossen wird, wenn psock gehalten wird, erhöhen wir einfach den Referenzzähler von psock, um Race Conditions zu vermeiden.
Mit diesem Patch wird sock_map_close() warten, bis der Backlog-Thread abgeschlossen ist, und alle ausstehenden Arbeiten abbrechen, falls der Backlog-Thread ausgeführt wird.
Wenn kein Backlog ausgeführt wird, werden alle ausstehenden Arbeiten, die bis dahin noch nicht gestartet wurden, bei Aufruf durch sk_psock_get() fehlschlagen, da der Referenzzähler von psock auf Null gesetzt wurde, und sk_psock_drop() wird alle Jobs über cancel_delayed_work_sync() abbrechen.
Zusammenfassend ist eine Synchronisation erforderlich, um den Backlog-Thread und den close()-Thread zu koordinieren.
Der von mir erfasste Panic: ''' 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.