{"api_version":"1","generated_at":"2026-10-03T07:06:54+00:00","cve":"CVE-2026-90138","urls":{"html":"https://cve.report/CVE-2026-90138","api":"https://cve.report/api/cve/CVE-2026-90138.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-90138","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-90138"},"summary":{"title":"vsock: don't check the listener's sk_err in vsock_accept()","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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-17 17:17:06","updated_at":"2026-09-17 17:17:06"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/36e5fa009f98a4edbe1783ac11c0df672b224742","name":"https://git.kernel.org/stable/c/36e5fa009f98a4edbe1783ac11c0df672b224742","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/c5a75d37c21e558cc6fad1597e732ead30745eed","name":"https://git.kernel.org/stable/c/c5a75d37c21e558cc6fad1597e732ead30745eed","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/491b368a0c6e5f28b615a50b0d384f5c25fde2a7","name":"https://git.kernel.org/stable/c/491b368a0c6e5f28b615a50b0d384f5c25fde2a7","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/b8c899cf5e7be29840a172c183dedd8d3e7a0287","name":"https://git.kernel.org/stable/c/b8c899cf5e7be29840a172c183dedd8d3e7a0287","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-90138","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90138","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d021c344051af91f42c5ba9fdedc176740cbd238 c5a75d37c21e558cc6fad1597e732ead30745eed git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d021c344051af91f42c5ba9fdedc176740cbd238 36e5fa009f98a4edbe1783ac11c0df672b224742 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d021c344051af91f42c5ba9fdedc176740cbd238 491b368a0c6e5f28b615a50b0d384f5c25fde2a7 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d021c344051af91f42c5ba9fdedc176740cbd238 b8c899cf5e7be29840a172c183dedd8d3e7a0287 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 3.9","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 3.9 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.110 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.52 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.6 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["net/vmw_vsock/af_vsock.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"c5a75d37c21e558cc6fad1597e732ead30745eed","status":"affected","version":"d021c344051af91f42c5ba9fdedc176740cbd238","versionType":"git"},{"lessThan":"36e5fa009f98a4edbe1783ac11c0df672b224742","status":"affected","version":"d021c344051af91f42c5ba9fdedc176740cbd238","versionType":"git"},{"lessThan":"491b368a0c6e5f28b615a50b0d384f5c25fde2a7","status":"affected","version":"d021c344051af91f42c5ba9fdedc176740cbd238","versionType":"git"},{"lessThan":"b8c899cf5e7be29840a172c183dedd8d3e7a0287","status":"affected","version":"d021c344051af91f42c5ba9fdedc176740cbd238","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["net/vmw_vsock/af_vsock.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"3.9"},{"lessThan":"3.9","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.110","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.52","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.6","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.110","versionStartIncluding":"3.9","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.52","versionStartIncluding":"3.9","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.6","versionStartIncluding":"3.9","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"3.9","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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."}],"providerMetadata":{"dateUpdated":"2026-09-17T16:06:36.528Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/c5a75d37c21e558cc6fad1597e732ead30745eed"},{"url":"https://git.kernel.org/stable/c/36e5fa009f98a4edbe1783ac11c0df672b224742"},{"url":"https://git.kernel.org/stable/c/491b368a0c6e5f28b615a50b0d384f5c25fde2a7"},{"url":"https://git.kernel.org/stable/c/b8c899cf5e7be29840a172c183dedd8d3e7a0287"}],"title":"vsock: don't check the listener's sk_err in vsock_accept()","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-90138","datePublished":"2026-09-17T16:06:36.528Z","dateReserved":"2026-09-11T19:38:34.788Z","dateUpdated":"2026-09-17T16:06:36.528Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-17 17:17:06","lastModifiedDate":"2026-09-17 17:17:06","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"90138","Ordinal":"1","Title":"vsock: don't check the listener's sk_err in vsock_accept()","CVE":"CVE-2026-90138","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"90138","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"vsock: don't check the listener's sk_err in vsock_accept()"}]}}}