Answer in brief
CVE-2026-97985 records a Unknown severity vulnerability in af_unix: Update last skb marker in manage_oob().. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=22dd70eb2c3d754862964377a75abafd3167346b <0630bfc773d85ac44da05b2c5a037dbbd39301ab || >=22dd70eb2c3d754862964377a75abafd3167346b <f1816b3d7ce80dcf086bb68ff5ae6e09520ca1fa || >=22dd70eb2c3d754862964377a75abafd3167346b <fc62a26493a98a0424d9dae2eb92a1daa1321f65 || >=22dd70eb2c3d754862964377a75abafd3167346b <94fd4debd2e3a69cf93e766c8b328a810c228119 || ae3f9e1221b31b18dbd4c4b85d08574996bbd973 || ba0db4638525b8b054b3d546b45f7e473f477027 || 022d81a709cd553bbe2db8675f8e824f4aee6284 || 16dc252e7007547a7b72a2c21022ef81fb45e6a3 || >=5.15.157 <5.16 || >=6.1.88 <6.2 || >=6.6.29 <6.7 || >=6.8.8 <6.9 | 0630bfc773d85ac44da05b2c5a037dbbd39301ab, f1816b3d7ce80dcf086bb68ff5ae6e09520ca1fa, fc62a26493a98a0424d9dae2eb92a1daa1321f65, 94fd4debd2e3a69cf93e766c8b328a810c228119, 5.16, 6.2, 6.7, 6.9 |
| Linux/Linuxgeneric | 6.9 | Not reported |
Published upstream
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 25, 2026
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); 1) skb -> OOB skb -> NULL send(sk[0], "ab", 2, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 2) 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); 3) 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.
Quoted source text, attributed separately from HOL analysis.