CVE-2026-98394 in Linux
Summary
by MITRE • 10/15/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within the Linux kernel’s Unix domain socket implementation involves an infinite busy-wait condition triggered by specific interactions between receive operations and out-of-band data handling. Specifically, when a process invokes recv with a zero-length buffer while using the MSG_PEEK flag on a blocking socket, the system enters a tight loop if the last packet in the queue is marked as Message Out of Band (MSG_OOB). This behavior deviates from established networking standards where such conditions typically result in an immediate return value rather than consuming CPU cycles indefinitely. The root cause lies within the unix_stream_read_generic function, which fails to properly handle the case where manage_oob returns NULL for a zero-length buffer request, leading to a logic error that prevents the function from exiting gracefully under blocking constraints.
From a technical perspective, this flaw represents a failure in input validation and state management within the kernel’s network stack. The unix_stream_read_generic routine is responsible for reading data from Unix domain sockets, which are used for inter-process communication on local systems. When MSG_PEEK is specified, the application intends to view incoming data without removing it from the queue. However, when combined with a zero-length buffer and blocking mode, the kernel’s expectation of available data conflicts with the actual state of the socket if only out-of-band markers are present. The manage_oob function determines how to handle these special messages, but in this specific edge case, its return value is not correctly interpreted by the caller, causing the loop condition to remain true and resulting in continuous CPU consumption without progress.
The operational impact of this vulnerability includes significant denial of service potential for local processes. An attacker or a buggy application can exploit this busy-wait state to consume 100 percent of one CPU core on the affected system. This resource exhaustion can degrade performance for other critical services running on the same host, effectively creating a localized denial of service condition. Unlike remote exploits that might crash the entire kernel, this issue primarily affects availability and responsiveness by tying up computational resources in an unyielding loop. The severity is heightened because it requires no special privileges to trigger if the attacker has access to create Unix domain sockets or interact with existing ones, making it a plausible vector for local resource exhaustion attacks.
This vulnerability aligns with CWE-835, which describes loops that consume excessive resources due to missing exit conditions, and can be mapped to MITRE ATT&CK technique T1496, Resource Hijacking, specifically under the sub-category of CPU consumption. To mitigate this issue, system administrators should ensure their Linux kernels are updated to versions where the af_unix subsystem has been patched to correctly return immediately when manage_oob returns NULL for zero-length buffers. This patch aligns the behavior with TCP standards, ensuring that recv(0, MSG_PEEK) returns 0 promptly regardless of blocking mode if no actual data is available beyond out-of-band markers. Additionally, implementing monitoring tools that detect sustained high CPU usage by socket-related processes can help identify such anomalies early in a production environment before they lead to significant service degradation.