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

  - smbclientrmmod 後の TCP タイマーデッドロックを修正します。これによりコミット e9f2517a3e18a54a3943c098d2226b245d488801 が戻されます。e9f2517a3e18 のコミットsmbclientrmmod 後の TCP タイマーデッドロックを修正は、LOCKDEP の null-ptr-deref を修正することが意図されています。これは CVE-2024-54680として言及されていますが、実際には何も修正されません。の問題はその上で再生できます。 [0] また、これは ef7134c7fc48 をコミットすることで変更を元に戻し、smb クライアントネットワークの名前空間の use-after-free を修正します。カーネル TCP ソケットを復活させることで、真の問題を導入しました。CIFS 接続で再接続が発生すると、ソケット状態は FIN_WAIT_1 に移行します。次に、tcp_close()のinet_csk_clear_xmit_timers_sync()により、ソケットのすべてのタイマーが停止します。受信 FIN パケットが失われた場合、ソケットは永久に FIN_WAIT_1 に保持され、このようなソケットが net.ipv4.tcp_max_orphans に漏洩する可能性があります。通常、FINはピアによって再送信できますが、ピアが接続を中止すると、問題が具体化します。私は正確なレポート [1] を指摘することで、これについてはプライベートで警告していましたが、偽造の修正が最終的に統合されました。したがって、この場合、タイマーを停止してこちら側の接続を最終的に kill すべきではありません。つまり、sk->sk_net_refcnt が 0 である TCP 用のカーネルソケットを使用してはなりません。カーネルソケットには、その netns に対する参照がありません。あるすべてのリソースをクリーンアップせずに、netns を破棄することが可能です。たとえば、トンネルデバイスは内部的に UDP ソケットを使用しますが、そのようなデバイスを削除せずに netns を破壊し、終了時にそれを完了させることができます。
    そうでないと、最後のアプリケーションが終了したときに netns が漏洩します。しかし、これは TCP ソケットにとっては問題となります。これは、TCP には、ソケットが close()d された後でも、接続を丁寧に閉じるためのタイマーがあるためです。ソケットとその netns の有効期間は、下層接続の有効期間とは異なります。ソケットユーザーが netns の有効期間を維持しない場合、ソケットが close()d され、その netns が解放された後にタイマーが起動され、use-after-free が発生する可能性があります。実際、当社ではこれまで、非常に多くの類似した問題を起こし、そのようなソケットを netns に対する参照を持つように変換しました。CIFS クライアントソケットを netns への参照を持つように変換したのはこのためですsk->sk_net_refcnt == 1。これは、何らかの方法で CIFS の範囲外として言及されており、e9f2517a3e18 では技術的に間違っています。*** は範囲内適切な修正**。LOCKDEP 問題に関しては、sock_lock_init_class_and_name() で LOCKDDEP キーを切り替える際に、モジュール refcount を更新することで、モジュールのアンロードを防ぐことができます。 [2] しばらくの間、偽造の修正を元に戻します。注意現在はソケット変換に sk_net_refcnt_upgrade() を使用できますが、バックポートを簡単にするために後でこれを別途使用します。
    (CVE-2025-22077)

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

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2025-22077

medium Nessus プラグイン ID 249058

バージョン 1.10