{"id":"CVE-2026-90138","summary":"vsock: don't check the listener's sk_err in vsock_accept()","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nvsock: don't check the listener's sk_err in vsock_accept()\n\nSyzbot reported an issue which can be reproduced with these steps:\n\tr0 = socket(AF_VSOCK, SOCK_STREAM, 0)\n\tbind(r0, {VMADDR_CID_ANY, PORT})\n\tconnect(r0, {VMADDR_CID_LOCAL, PORT}) -\u003e -1, EPROTO (self-connect)\n\tlisten(r0, backlog)                   -\u003e 0\n\tr1 = socket(AF_VSOCK, SOCK_STREAM, 0)\n\tconnect(r1, {VMADDR_CID_LOCAL, PORT}) -\u003e 0\n\taccept(r0)                            -\u003e -1, EPROTO (stale sk_err)\n\nBasically, it creates a socket (r0) and triggers a self-connect after\nbinding it. This self-connect fails with EPROTO because it loops back\nto r0 while the socket is still in the TCP_SYN_SENT state, causing it\nto be incorrectly dispatched to the connecting-client path. The\nunexpected packet type encountered there sets sk_err to EPROTO.\n\nAfter that, it invokes a listen() call on the same socket. This\nlisten() call succeeds because the kernel's listening path never\ninspects or clears sk_err. Then, a new socket (r1) is created as a\nnormal client and connects to r0. However, vsock_accept() rejects this\nincoming connection because the listener's sk_err still holds the\nEPROTO error from the earlier failed self-connect.\n\nThis rejection causes the child socket created for r1's connection to\nnever be freed on virtio or hyperv transports; only the VMCI transport\nimplements pending_work to revisit and clean up a rejected socket.\n\nFor a non-blocking connect(), vsock_connect() may return -EINPROGRESS\nimmediately, and vsock_connect_timeout() can later set sk-\u003esk_err\nasynchronously.\n\nSince no vsock transport ever sets sk_err on a socket while it is in\nTCP_LISTEN state, checking it in vsock_accept() serves no purpose and\nonly carries forward errors left behind by earlier, unrelated\nconnection attempts on the same socket. Remove the checks so accept()\nno longer rejects valid incoming connections because of a stale\nerror, which also avoids the resource leak described above.","modified":"2026-09-18T03:48:35.681990873Z","published":"2026-09-17T16:06:36.528Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90138.json"},"references":[{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"},{"type":"WEB","url":"https://git.kernel.org/stable/c/36e5fa009f98a4edbe1783ac11c0df672b224742"},{"type":"WEB","url":"https://git.kernel.org/stable/c/491b368a0c6e5f28b615a50b0d384f5c25fde2a7"},{"type":"WEB","url":"https://git.kernel.org/stable/c/b8c899cf5e7be29840a172c183dedd8d3e7a0287"},{"type":"WEB","url":"https://git.kernel.org/stable/c/c5a75d37c21e558cc6fad1597e732ead30745eed"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90138.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90138"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"d021c344051af91f42c5ba9fdedc176740cbd238"},{"fixed":"c5a75d37c21e558cc6fad1597e732ead30745eed"},{"fixed":"36e5fa009f98a4edbe1783ac11c0df672b224742"},{"fixed":"491b368a0c6e5f28b615a50b0d384f5c25fde2a7"},{"fixed":"b8c899cf5e7be29840a172c183dedd8d3e7a0287"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90138.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.9.0"},{"fixed":"6.12.110"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.52"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.2.6"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90138.json"}}],"schema_version":"1.9.0"}