CVE-2026-64109 in Linux
Riassunto
di VulDB • 20/07/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
af_unix: Correzione della lettura Use-After-Free (UAF) di tail->len in unix_stream_data_wait()
unix_stream_data_wait() esegue skb_peek_tail(&sk->sk_receive_queue) senza detenere alcun lock che impedisca lo sbiancamento e la liberazione degli SKB da tale coda. Questo comportamento è presente sin dal commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). La prima conseguenza di ciò è che il confronto puntatori `tail != last` può risultare falso anche se `last` si riferisce semanticamente a un SKB già liberato, mentre `tail` punta a un nuovo SKB allocato nello stesso indirizzo; questo potrebbe causare unix_stream_data_wait() nel bloccarsi erroneamente dopo l'arrivo di nuovi dati, ma solo in uno scenario peculiare in cui una recv() con peek e una normale recv() sullo stesso socket sono soggette a race condition, il che probabilmente non costituisce un problema reale.
Tuttavia, dal commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"), `tail` viene effettivamente dereferenziato, il che può causare una UAF nel seguente scenario di race condition (dove test_setup() esegue in modalità single-threaded e successivamente test_thread1() e test_thread2()) vengono eseguiti concorrentemente su due thread: ``` static int socks[2];
void test_setup(void) {
socketpair(AF_UNIX, SOCK_STREAM, 0, socks); send(socks[1], "A", 1, 0);
int peekoff = 1; setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff));
} void test_thread1(void) {
char dummy; recv(socks[0], &dummy, 1, MSG_PEEK);
} void test_thread2(void) {
char dummy; recv(socks[0], &dummy, 1, 0);
shutdown(socks[1], SHUT_WR);
} ```
quando si verifica questa race condition: ``` thread1 thread2 unix_stream_read_generic mutex_lock(&u->iolock) skb_peek(&sk->sk_receive_queue) skb_peek_next(skb, &sk->sk_receive_queue) mutex_unlock(&u->iolock) unix_stream_read_generic unix_state_lock(sk) skb_peek(&sk->sk_receive_queue) unix_state_unlock(sk) unix_stream_data_wait unix_state_lock(sk) tail = skb_peek_tail(&sk->sk_receive_queue) spin_lock(&sk->sk_receive_queue.lock) __skb_unlink(skb, &sk->sk_receive_queue) spin_unlock(&sk->sk_receive_queue.lock) consume_skb(skb) [libera l'SKB]
`tail != last`: false `tail`: true `tail->len != last_len` ***UAF*** ```
La correzione della UAF consiste nel rimuovere la lettura di tail->len; il controllo su tail->len avrebbe senso solo se gli SKB nella coda di ricezione di un socket UNIX potessero crescere, cosa che non può più accadere.
Kuniyuki ha spiegato:
> Quando il commit 869e7c62486e ("net: af_unix: implement stream sendpage support") ha aggiunto il supporto a sendpage(), i dati potevano essere accodati all'ultimo SKB nella coda del
If you want to get best quality of vulnerability data, you may have to visit VulDB.