Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - vsock:vsock_accept() でリスナーのsk_errをチェックしません Syzbot は、次の手順で再現できる問題を報告しました: r0 = socket(AF_VSOCK, SOCK_STREAM, 0) bind(r0, {VMADDR_CID_ANY, PORT}) connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) listen(r0, backlog) -> 0 r1 = socket(AF_VSOCK, SOCK_STREAM, 0) connect(r1, {VMADDR_CID_LOCAL、ポート})-> 0 accept(r0) -> -1、EPROTO (stale sk_err) 基本的にはソケット(r0)を作成し、これをバインドした後に自己接続をトリガーします。ソケットがまだ TCP_SYN_SENT 状態にある間に r0 にループバックし、接続クライアントのパスに間違ってディスパッチされるため、この自己接続は EPROTO で失敗します。そこで遭遇した予期しないパケットタイプが、sk_err EPROTO に設定されます。その後、同じソケットでlisten()呼び出しを呼び出します。このlisten()呼び出しは、カーネルのリスニングパスがsk_errを検査またはクリアしないために成功します。次に、新しいソケット(r1)が通常のクライアントとして作成され、r0に接続されます。ただし、リスナーのsk_errに以前失敗した自己接続からの EPROTO エラーがまだ保持されているため、vsock_accept() はこの着信接続を拒否します。この拒否により、r1 の接続用に作成された子ソケットが、virtio または hyperv のトランスポートで決して解放されなくなります。VMCI トランスポートのみが、拒否されたソケットを再アクセスしてクリーンアップするpending_workを実装します。ノンブロッキング connect() の場合、vsock_connect() は -EINPROGRESS をすぐに返すことができ、vsock_connect_timeout() は後で sk->sk_err を非同期に設定できます。vsockトランスポートは、ソケットがTCP_LISTEN状態の間、ソケットにsk_errを設定することはないため、vsock_accept()でチェックすることは何の役にも立たず、同じソケットでの以前の無関係な接続試行によって残されたエラーを転送するだけです。accept() が古いエラーによって有効な着信接続を拒否しないようにチェックを削除し、上記のリソース漏洩も回避します。(CVE-2026-90138)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2026-90138

medium Nessus プラグイン ID 347446

バージョン 1.13