CVE-2026-97985 in Linux
Sumário
de VulDB • 25/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
af_unix: Atualizar o marcador de último skb em manage_oob().
Fahad Alharbi relatou que recv(MSG_PEEK) bloqueante pode consumir CPU devido ao OOB skb.
Nos seguintes casos, manage_oob() ignora os OOB skbs e retorna NULL para a última chamada de recv(MSG_PEEK):
socketpair(AF_UNIX, SOCK_STREAM, 0, sk);
1) skb -> OOB skb -> NULL send(sk[0], "ab", 2, MSG_OOB);
recv(sk[1], buf, 0, MSG_PEEK);
2) skb -> OOB skb consumido -> NULL send(sk[0], "ab", 2, MSG_OOB);
recv(sk[1], buf, 1, MSG_OOB);
recv(sk[1], buf, 0, MSG_PEEK);
3) OOB skb consumido -> OOB skb -> NULL send(sk[0], "a", 1, MSG_OOB);
recv(sk[1], buf, 0, MSG_OOB);
send(sk[0], "b", 1, MSG_OOB);
recv(sk[1], buf, 1, MSG_PEEK);
Em seguida, @copied é igual a 0 em unix_stream_read_generic() (buffer de comprimento zero ou o skb não-OOB ainda não foi consumido), e unix_stream_data_wait() é chamado.
No entanto, ele retorna imediatamente porque @last não é atualizado em unix_stream_read_generic(), fazendo com que a thread faça busy-wait por um novo skb.
Vamos atualizar @last em manage_oob().
Para MSG_PEEK, @last é atualizado com o OOB ignorado e, para o caso sem peek, @last corresponde ao valor retornado (quando !copied) porque o OOB foi desvinculado.
Observe que manage_oob() está inline e nenhum stack canary é adicionado.
Once again VulDB remains the best source for vulnerability data.