CVE-2026-98394
NoneCVSS
—
EPSS
0.2%
Published
Oct 14, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel can let one program on the same machine make the whole system slow or unresponsive by spinning the CPU in a tight loop.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
A blocking recv(MSG_PEEK) with zero-length buffer on an AF_UNIX stream socket whose final queued skb is an OOB message causes unix_stream_read_generic to spin indefinitely in a busy-wait loop instead of returning zero.
Why it matters to the business
A local process can drive one or more CPU cores to 100 percent utilization, starving other workloads and potentially rendering the system or container unresponsive until the socket is closed or the process is terminated.
How an attack unfolds
An attacker creates an AF_UNIX stream socket pair, sends an out-of-band message as the final skb, then issues a blocking zero-length MSG_PEEK recv; the kernel enters the busy-wait and never yields, producing a local denial of service.
How to fix it
Apply the upstream kernel patch that returns immediately when manage_oob returns NULL for a zero-length buffer; rebuild and deploy the updated kernel or distribution package containing the fix.
How to confirm the fix worked
Confirm the patched kernel source contains the early return after manage_oob returns NULL; on a running system, verify that a zero-length blocking MSG_PEEK recv on an OOB-terminated AF_UNIX socket now returns zero without spinning.
Typical attack path
- Create AF_UNIX SOCK_STREAM socket pair
- Send MSG_OOB data so it becomes the last skb
- Call recv with flags MSG_PEEK and length zero while the socket is blocking
- Observe sustained high CPU usage in the kernel thread handling the socket
How to detect it
Look in kernel logs or tracing for repeated calls inside unix_stream_read_generic associated with AF_UNIX sockets; high sustained CPU usage by kernel threads handling unix sockets with no corresponding application progress may indicate exploitation.
What your security team should do
- Prioritize patching production kernel packages within the normal change window given the low EPSS and absence from KEV
- Add the busy-wait condition to internal kernel-fuzzing test suites
- Monitor for any downstream Linux distributions releasing updated packages
The record
In the Linux kernel, the following vulnerability has been resolved: af_unix: Return immediately when manage_oob() returns NULL for 0-length buffer. Fahad Alharbi reported that recv(0, MSG_PEEK) triggers busy-wait in unix_stream_read_generic() if recv() is blocking and the last skb in the queue is MSG_OOB skb. In such a situation, TCP returns 0 immediately regardless of blocking or non-blocking. Let's follow the behaviour.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|