CVE-2023-53836 in Linux
Zusammenfassung
von VulDB • 27.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
bpf, sockmap: Behebung eines Race Conditions bei der skb-Referenzzählung (refcnt) nach Änderungen an den Sperrmechanismen
Es besteht ein Race Condition, bei dem skbs aus dem sk_psock_backlog referenziert werden können, nachdem die Userspace-Seite bereits skb_consumed() für den sk_buff aufgerufen und dessen refcnt auf 0 reduziert hat, was zu einem Use-After-Free führt.
Der Ablauf ist wie folgt:
while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)
Die Funktion sk_psock_queue_msg() fügt die Nachricht (msg) in die ingress_msg-Warteschlange ein. Dies ist das, was die Anwendung liest, wenn recvmsg() aufgerufen wird. Eine Anwendung kann dies jederzeit lesen, nachdem die Nachricht in die Warteschlange gestellt wurde. Der recvmsg-Hook liest ebenfalls msg->skb und ruft nach dem Lesen durch den Userspace consume_skb(skb) auf, wodurch der sk_buff effektiv freigegeben wird.
Der Race Condition liegt jedoch darin, dass die Backlog-Warteschlange weiterhin eine Referenz auf den skb enthält und skb_dequeue() aufruft. Wenn das skb_dequeue nach dem Lesen und Freigeben des skbs durch den Benutzer stattfindet, liegt ein Use-After-Free vor.
Der Fall !ingress leidet nicht unter diesem Problem, da er sendmsg_*(sk, msg) verwendet, das den sk_buff nicht weiter unten im Stack übergibt.
Der folgende Splat wurde mit 'test_progs -t sockmap_listen' beobachtet:
[ 1022.710250][ T2556] general protection fault, ...
[...]
[ 1022.712830][ T2556] Workqueue: events sk_psock_backlog
[ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x100
[ 1022.713633][ T2556] Call Trace:
[ 1022.713933][ T2556] <TASK>
[ 1022.714233][ T2556] sk_psock_backlog+0x27a/0x300
If you want to get best quality of vulnerability data, you may have to visit VulDB.