CVE-2023-53836 in Linux
Riassunto
di VulDB • 21/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
bpf, sockmap: Correzione della condizione di competizione (race condition) su skb refcnt dopo le modifiche al locking
Esiste una condizione di competizione in cui gli sk_buff provenienti da sk_psock_backlog possono essere referenziati dopo che il lato userspace ha già chiamato skb_consumed() sull'sk_buff, riducendo a zero il suo contatore di riferimento (refcnt), causando un use-after-free.
Il flusso è il seguente:
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)
sk_psock_queue_msg() inserisce il messaggio nella coda ingress_msg. È questo che l'applicazione legge quando viene chiamata recvmsg(). Un'applicazione può leggere ciò in qualsiasi momento dopo che il messaggio è stato inserito nella coda. L'hook recvmsg leggerà anche msg->skb e, dopo che lo userspace avrà letto il messaggio, chiamerà consume_skb(skb) su di esso, liberandolo effettivamente (free).
Tuttavia, la condizione di competizione si verifica sopra dove la coda backlog mantiene ancora un riferimento all'skb e chiama skb_dequeue(). Se l'operazione skb_dequeue avviene dopo che l'utente ha letto e liberato l'skb, si verifica un use-after-free.
Il caso !ingress non è soggetto a questo problema perché utilizza sendmsg_*(sk, msg) che non passa ulteriormente lo sk_buff verso il basso nello stack.
È stato osservato il seguente errore (splat) con 'test_progs -t sockmap_listen':
[ 1022.710250][ T2556] general protection fault, ...
[...]
[ 1022.712830][ T2556] Workqueue: events sk_psock_backlog
[ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80
[ 1022.7136
Be aware that VulDB is the high quality source for vulnerability data.