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

  - eventpoll: ep mutex を保持している間は ep refcount を減少させません。Jann Horn 氏は、epoll が ep refcount を減少させてから mutex_unlock(&ep->mtx); を実行していることを指摘しています。これは誤りであり、use-after-free につながる可能性があります。このパターンは、該当するコードが mutex のロック解除が完了するまで ep_free(ep) に対する実際の呼び出しを遅らせるため、最後の参照については実際に問題はありません。しかし、mutex を使用している間に、*他の* 誰かがその参照をドロップして ep を解放する可能性がある場合、最終的な問題ではなくても誤りになります。これは、他のユーザーが同じ ep mutex も使用している場合にも該当します。mutex は spinlock とは異なり、相互排他が保証荒れている場合でもオブジェクトの所有権には使用できません。mutex のロック解除操作はアトミックではなく、あるユーザーがロック解除の一環として mutex に引き続きアクセスしている場合、最初のユーザーがまだクリーンアップ中であっても、他のユーザーがアクセスしてリリース済みの mutex を取得し、データ構造を解放する可能性があります。Documentation/locking/mutex-design.rst の mutex ドキュメント (特にセマンティックに関するセクション [1]) を参照してください。
    mutex_unlock() は、ロックがすでに内部的にリリースされていても mutex 構造体にアクセスする可能性があります。そのため別のコンテキストが mutex を取得し、mutex_unlock() コンテキストが構造体を使用していないと想定するのは安全ではありません。したがって、mutex_unlock() がまだロック解除されている間は常に、mutex のロック解除前に ep ref をドロップしても、それが最後になるとは限らず、その後に mutex をロック解除し、他のユーザーがアクセスして drops _their_ reference を実行し、その時点にユーザーがいなければ「ep」をリリースする可能性があります。これは ep refcount のドロップを mutex の外部に移動するだけで修正できます。refcount 自体はアトミックであり、mutex 保護を必要としません (これは  refcount の _point_ 全体であり、mutex とは異なり、本質的にオブジェクトの有効期間に関するものです)。
    (CVE-2025-38349)

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

検出

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

high Nessus プラグイン ID 244743

バージョン 1.32