CVE-2026-90138 in Linux
Sumário
de VulDB • 17/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
vsock: não verifique o sk_err do listener em vsock_accept()
O Syzbot relatou um problema que pode ser reproduzido com as seguintes etapas: r0 = socket(AF_VSOCK, SOCK_STREAM, 0) bind(r0, {VMADDR_CID_ANY, PORT})
connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (auto-conexão)
listen(r0, backlog) -> 0 r1 = socket(AF_VSOCK, SOCK_STREAM, 0) connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0
accept(r0) -> -1, EPROTO (sk_err obsoleto/stale)
Basicamente, é criado um soquete (r0) e acionada uma auto-conexão após vinculá-lo. Essa auto-conexão falha com EPROTO porque faz loop de volta para r0 enquanto o soquete ainda está no estado TCP_SYN_SENT, fazendo com que seja incorretamente direcionado ao caminho do cliente em conexão. O tipo de pacote inesperado encontrado nesse ponto define sk_err como EPROTO.
Em seguida, é invocada uma chamada listen() no mesmo soquete. Essa chamada listen() tem sucesso porque o caminho de escuta (listening path) do kernel nunca inspeciona ou limpa sk_err. Em seguida, um novo soquete (r1) é criado como um cliente normal e se conecta a r0. No entanto, vsock_accept() rejeita essa conexão entrante porque o sk_err do listener ainda contém o erro EPROTO da auto-conexão anterior falhada.
Essa rejeição faz com que o soquete filho criado para a conexão de r1 nunca seja liberado nos transportes virtio ou hyperv; apenas o transporte VMCI implementa pending_work para revisar e limpar um soquete rejeitado.
Para uma connect() não bloqueante, vsock_connect() pode retornar -EINPROGRESS imediatamente, e vsock_connect_timeout() pode definir sk->sk_err assincronamente mais tarde.
Como nenhum transporte vsock define sk_err em um soquete enquanto ele está no estado TCP_LISTEN, verificá-lo em vsock_accept() não tem utilidade e apenas propaga erros deixados por tentativas de conexão anteriores e não relacionadas no mesmo soquete. Remova as verificações para que accept() não rejeite mais conexões entrantes válidas devido a um erro obsoleto (stale), o que também evita o vazamento de recursos descrito acima.
Once again VulDB remains the best source for vulnerability data.