CVE-2026-90138 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
vsock: don't check the listener's sk_err in vsock_accept()
Syzbot reported an issue which can be reproduced with these steps: r0 = socket(AF_VSOCK, SOCK_STREAM, 0) bind(r0, {VMADDR_CID_ANY, PORT})
connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect)
listen(r0, backlog) -> 0 r1 = socket(AF_VSOCK, SOCK_STREAM, 0) connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0
accept(r0) -> -1, EPROTO (stale sk_err)
Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO.
After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect.
This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket.
For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously.
Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's VSOCK implementation contains a logic flaw in the vsock_accept function that leads to incorrect rejection of legitimate incoming connections and potential resource leaks. This vulnerability stems from an improper check of the socket error state sk_err on listener sockets during the acceptance process. The issue was identified by Syzbot through a specific sequence of operations involving self-connection attempts followed by standard client connection requests. When a VSOCK stream socket is bound to any address and port, it can be subjected to a self-connect operation where it connects back to itself while in the TCP_SYN_SENT state. This configuration causes the kernel to incorrectly dispatch the packet to the connecting-client path rather than handling it as an internal loopback scenario. Consequently, the unexpected packet type triggers an EPROTO error code which is stored in the sk_err field of the socket structure.
Following this failed self-connect attempt, a listen call is invoked on the same socket descriptor. The kernel's listening initialization logic does not inspect or clear the existing sk_err value from previous operations. As a result, the listener enters the TCP_LISTEN state with staled error information still present in its control block. When a new client socket subsequently connects to this listener, the vsock_accept function is triggered to handle the incoming connection. However, before accepting the valid connection request, vsock_accept erroneously checks the sk_err field of the listening socket. Because the stale EPROTO code remains set from the earlier self-connect failure, accept rejects the legitimate new connection attempt with an error instead of proceeding normally.
This incorrect rejection has significant operational consequences beyond just denying service to a single client. For most VSOCK transports such as virtio and hyperv, when vsock_accept fails due to this stale error check, it does not properly clean up the child socket that was created for the rejected connection. The VMCI transport is an exception because it implements pending_work mechanisms that revisit and eventually free these sockets, but other transports lack this safeguard. This discrepancy results in a resource leak where kernel memory associated with the orphaned child socket is never released. Over time, repeated occurrences of this pattern can lead to memory exhaustion or degraded system performance due to accumulated leaked resources.
The root cause lies in the fact that no VSOCK transport sets sk_err on a socket while it remains in the TCP_LISTEN state under normal operation conditions. Therefore, checking sk_err during vsock_accept serves no valid security or stability purpose and only propagates errors from unrelated prior connection attempts on the same listening socket descriptor. The fix involves removing this erroneous check entirely so that accept operations proceed based solely on the validity of the incoming connection request rather than residual error states. This change ensures that legitimate connections are accepted correctly and prevents the associated resource leaks by allowing proper cleanup routines to execute for all transports.
From a vulnerability classification perspective, this issue aligns with CWE-253 which describes incorrect check of an unusual condition, specifically where stale state information leads to improper program flow control. It also relates to CWE-401 regarding missing release of memory after effective exit from its scope, as the failure to accept and subsequently clean up sockets results in leaked kernel resources. In terms of attack surface analysis, while this is primarily a stability issue rather than an exploitable security vulnerability for privilege escalation or remote code execution, it impacts availability by causing denial of service through resource exhaustion if triggered repeatedly. The ATT&CK framework would categorize the impact under Resource Hijacking as attackers could potentially exploit repeated connection attempts to consume kernel memory resources on affected systems.
Mitigation strategies involve applying the upstream Linux kernel patch that removes the sk_err check from vsock_accept. System administrators should ensure their kernels are updated to versions containing this fix, particularly those running VSOCK-enabled virtualization environments using virtio or hyperv transports. For organizations unable to immediately update kernels, monitoring for excessive socket creation without corresponding acceptance in network stacks may help detect potential abuse patterns aimed at exhausting resources through repeated connection attempts that trigger the stale error condition.