PT-2026-98649 · Linux · Linux
CVE-2026-97985
·
Publicado
2026-09-25
·
Atualizado
2026-09-25
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
In the Linux kernel, the following vulnerability has been resolved:
af unix: Update last skb marker in manage oob().
Fahad Alharbi reported that blocking recv(MSG PEEK) could hog CPU
due to OOB skb.
In the following cases, manage oob() skips OOB skb(s) and returns
NULL for the last recv(MSG PEEK):
socketpair(AF UNIX, SOCK STREAM, 0, sk);
-
skb -> OOB skb -> NULL send(sk[0], "ab", 2, MSG OOB); recv(sk[1], buf, 0, MSG PEEK);
-
skb -> consumed OOB skb -> NULL send(sk[0], "ab", 2, MSG OOB); recv(sk[1], buf, 1, MSG OOB); recv(sk[1], buf, 0, MSG PEEK);
-
consumed OOB skb -> 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);
Then, @copied is 0 in unix stream read generic() (zero-length buffer,
or non-OOB skb is not yet consumed), and unix stream data wait() is
called.
However, it returns immediately because @last is not updated in
unix stream read generic(), and the thread busy-waits for a new skb.
Let's update @last in manage oob().
For MSG PEEK, @last is updated with the skipped OOB, and for the
non-peek case, @last matches the returned value (when !copied)
because OOB is unlinked.
Note that manage oob() is inlined and no stack canary is added.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux