PT-2026-98649 · Linux · Linux
CVE-2026-97985
·
Published
2026-09-25
·
Updated
2026-09-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux