CVE-2026-97985 in Linux
Resumen
por VulDB • 2026-09-25
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
af_unix: Actualizar el marcador del último skb en manage_oob().
Fahad Alharbi informó que recv(MSG_PEEK) bloqueante podría consumir excesivamente la CPU debido a un OOB skb.
En los siguientes casos, manage_oob() omite los OOB skbs y devuelve NULL para la última llamada a 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);
A continuación, @copied es igual a 0 en unix_stream_read_generic() (buffer de longitud cero o el OOB skb no ha sido consumido aún), y se llama a unix_stream_data_wait().
Sin embargo, esta función devuelve inmediatamente porque @last no se actualiza en unix_stream_read_generic(), lo que provoca que el hilo realice busy-waiting por un nuevo skb.
Actualicemos @last en manage_oob().
Para MSG_PEEK, @se actualiza con el OOB omitido, y para el caso sin peek, @last coincide con el valor devuelto (cuando !copied) porque el OOB se desvincula.
Tenga en cuenta que manage_oob() está integrada (inline) y no se añade ninguna canary de pila (stack canary).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.