{"cve":"CVE-2026-90138","nvd":{"published":"2026-09-17T17:17:06.407","modified":"2026-10-21T13:20:38.710","status":"Received","description":"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}) -> -1, EPROTO (self-connect)\n\tlisten(r0, backlog)                   -> 0\n\tr1 = socket(AF_VSOCK, SOCK_STREAM, 0)\n\tconnect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0\n\taccept(r0)                            -> -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->sk_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.","cvss_v4":null,"cvss_v3":null,"cwes":[],"references":["https://git.kernel.org/stable/c/36e5fa009f98a4edbe1783ac11c0df672b224742","https://git.kernel.org/stable/c/491b368a0c6e5f28b615a50b0d384f5c25fde2a7","https://git.kernel.org/stable/c/64348c55dd7596ca2c033dcd102af44bdd7e8acd","https://git.kernel.org/stable/c/b8c899cf5e7be29840a172c183dedd8d3e7a0287","https://git.kernel.org/stable/c/c5a75d37c21e558cc6fad1597e732ead30745eed"],"products":[],"source":"nvd","synced_at":"2026-10-22T16:41:11.231219466+00:00"},"epss":{"cve":"CVE-2026-90138","score":0.00206,"percentile":0.10561,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}