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

  - net:GSO フレームの xmit エラーを消費します。udpgro_frglist.sh および udpgro_bench.sh は、現在 NIPA で最も不安定なテストです。これらはまったく同じ方法で失敗します。TCP GRO テストは時折ストールし、テストは 10 分後に強制終了されます。これらのテストでは、veth を使用して GRO をシミュレートします。これらはマイナーな (return XDP_PASS;) を添付しますTSO を強制的にオフにして NAPI をオンにするための XDP プログラム。障害モードを掘り下げると、接続が完全に停止していることがわかります。送信者のsnd_nxtはシーケンス番号 N [1] ですが、受信者は、最大 N + 3 * MSS [2] を受信したと主張しています(rcv_nxt)。パズルの最後のピースは、送信者の rtx キューが空ではないということです (rtx キューのブロックがシーケンス番号 N - 4 * MSS [3] であるとします)。この状態で、送信者は rtx キューから、単一のセグメントと、シーケンス番号 N-4*MSS:N-3*MSS [3] で再送信を送信します。受信者はそれを認識し、N + 3 * MSS [2]までACKで応答します。
    しかし、送信者は、そこまで遠くにデータを送信した記憶がないため、この ack をTCP_ACK_UNSENT_DATAとして拒否します [1]。そして私たちは行き詰まっています。根本的な原因は、xmit リターンコードの混乱です。veth は、フレームを xmit できない場合、エラーを返します。最終的には、次のような損失イベントが発生します。
    ------------------------------------------------- |GSOスーパーフレーム1 |GSOスーパーフレーム2 | |-----------------------------------------------| |セグ |セグ |セグ |セグ |セグ |セグ |セグ |セグ | |1 |2 |3 |4 |5 |6 |7 |8 |------------------------------------------------- x ok ok <ok>| ok ok ok <x> \\ snd_nxt x は veth によって失われたパケットを意味し、ok はそれが通過したことを意味します。このテストでは veth は TSO を無効にしているため、個々のセグメントが表示されます。セグメント 1 は再送信キューにあり、再送信されます。では、明らかにセグ 8 まで送信したにもかかわらず、なぜ送信者はsnd_nxt進まなかったのでしょうか?tcp_write_xmit() は、コアからのリターンコードを、データがまったく送信されていないことを意味すると解釈します。TCP は個々のセグメントではなく GSO スーパーフレームを扱うため、問題の核心は、単一のセグメントの損失がすべての損失と解釈される可能性があることです。TCP は、GSO フレームの最後のセグメントの最後のリターンコードのみを表示します(上の図の<>括弧内)。もちろん、問題を発生させるには、Qdiscのないセットアップまたはデバイスが必要です。
    そうでなければ、Qdisc レイヤーはプロトコルレイヤーをデバイスエラーから完全に切断します。弊社は複数の方法でこれを修正することができます。1) veth がパケットを失った時にエラーを返さないようにします。これは過去にやったことだと思いますが、問題が再発し続け、デバッグするのは面倒です。ほくろをたたくゲームは素晴らしいものではありません。2) くそーリターンコードを修正ドキュメントでは NETDEV_TX_OK と NETDEV_TX_BUSY についてのみ説明しているので、ndo_start_xmit() からのリターンコードをブーリアンにする必要があるかもしれません。私はそれが一番気に入っていますが、おそらく古い、実際にはネットワークではないプロトコルが苦しむでしょう。3)TCPにエラーを無視させますTCPがip_queue_xmit()の結果を解釈することからどのような利点を得るかは私には完全にはわかりませんか? 具体的には、接続が確立され、データをプッシュすると、パケットロスはパケットロスにすぎませんか?4)この修正 Qdisc-less+GSO の場合の rc は、信頼できないため無視します。TCQ_F_CAN_BYPASSの場合は、すでに常に OK を返しています。Qdisc-less の場合、もう少し保守的に、GSO エラーだけをマスクしておきましょう。このパスは、CAN、MCTP などの非 IP ネットワークによりたどられるため、古いものを回帰させる可能性があります。これは最も簡単ですが、おそらく最もハッキーな修正でもありますか? 同様の修正が過去に Eric によって提案されましたが、元の報告者が OOT ドライバーで作業しており、フィードバックを提供していなかったため、コミットされることはありませんでした(リンクを参照)。(CVE-2026-43194)

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

検出

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

high Nessus プラグイン ID 312744

バージョン 1.14