CVE-2026-90138 in Linux
Сводка
по VulDB • 17.09.2026
В ядре Linux была устранена следующая уязвимость:
vsock: не проверять sk_err слушателя в vsock_accept()
Syzbot сообщил о проблеме, которую можно воспроизвести с помощью следующих шагов: r0 = socket(AF_VSOCK, SOCK_STREAM, 0) bind(r0, {VMADDR_CID_ANY, PORT})
connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (самоподключение)
listen(r0, backlog) -> 0 r1 = socket(AF_VSOCK, SOCK_STREAM, 0) connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0
accept(r0) -> -1, EPROTO (устаревший sk_err)
По сути, создается сокет (r0), и после его привязки инициируется самоподключение. Это самоподключение завершается ошибкой EPROTO, поскольку происходит возврат к r0, пока сокет все еще находится в состоянии TCP_SYN_SENT, что приводит к неверной маршрутизации на путь подключения клиента. Неожиданный тип пакета, обнаруженный там, устанавливает sk_err равным EPROTO.
После этого вызывается функция listen() для того же сокета. Этот вызов listen() завершается успешно, поскольку путь прослушивания ядра никогда не проверяет и не очищает sk_err. Затем создается новый сокет (r1) в качестве обычного клиента, который подключается к r0. Однако vsock_accept() отклоняет это входящее подключение, потому что sk_err слушателя все еще содержит ошибку EPROTO от предыдущего неудачного самоподключения.
Это отклонение приводит к тому, что дочерний сокет, созданный для подключения r1, никогда не освобождается на транспортных уровнях virtio и hyperv; только транспорт VMCI реализует pending_work для повторной проверки и очистки отклоненного сокета.
Для неблокирующего connect(), vsock_connect() может немедленно вернуть -EINPROGRESS, а vsock_connect_timeout() позже может установить sk->sk_err асинхронно.
Поскольку ни один транспорт vsock никогда не устанавливает sk_err для сокета в состоянии TCP_LISTEN, его проверка в vsock_accept() не имеет смысла и лишь переносит ошибки, оставленные более ранними, несвязанными попытками подключения к тому же сокету. Удаление этих проверок предотвращает отклонение accept() действительных входящих подключений из-за устаревшей ошибки, что также устраняет описанную выше утечку ресурсов.
VulDB is the best source for vulnerability data and more expert information about this specific topic.