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

  - fsINT_MAX を超えるファイル記述子テーブル割り当てを防ぎます。sysctl_nr_open が非常に高い値に設定されている場合例systemd で設定されている 1073741816、制限に近いファイル記述子を使用しようとするプロセスが INT_MAX を超える大量のメモリ割り当てを発生させ、 mm/slub.cの警告で警告CPU0 PID44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 これは、リクエストされたサイズがINT_MAXを超えてエミットするかどうかをkvmalloc_array()とkvmalloc()がチェックするために発生します。割り当てが __GFP_NOWARN でフラグが立てられていない場合、警告が表示されます。具体的には、nr_open が 1073741816 (0x3ffffff8) に設定され、プロセスが dup2oldfd、1073741880を呼び出すとき、カーネルは割り当てを試みます。- ファイル記述子の配列1073741880 * 8 バイト = 8,589,935,040 bytes - 複数のビットマップ〜400MB - 合計割り当てサイズ> 8GBINT_MAX = 2,147,483,647 を実行include <unistd.h> #include<sys/resource.h> int main() { struct rlimit rlim = {1073741824, 1073741824};
    setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // 警告リターン 0 を発生させます} 3. mm/slub.c:5027 systemd コミット a8b627a の dmesg の警告に従い、fs.nr_open の可能な最大値への自動更新を導入しました。その理由は、メモリが適切に説明されるため、メモリコントロールグループmemcgを備えたシステムでは個別のファイル記述子の制限はもはや必要ないということでした。しかし、この変更は次の内容を見落としていました1. カーネルの割り当て関数は、依然として memcg アカウンティングにかかわらず最大サイズとして INT_MAX を強制します 2. ファイル記述子の制限を正当にテストするプログラムおよびテストは、不注意に大量の割り当てを発生させる可能性があります 3。その結果生じる割り当て>8GBは です。実行的でないと常に失敗します。systemd のアルゴリズムは INT_MAX で始まり、カーネルが受け入れるまで値を半分に減らし続けます。ほとんどのシステムで、これにより nr_open は 1073741816 (0x3ffffff8) に設定され、ファイル記述子は 1GB 未満になります。
    プロセスが通常の操作でこの制限の近くでファイル記述子を使用することはほとんどありませんが、特定のセルフテストtools/testing/selftests/core/unshare_test.c などやファイル記述子の制限をテストするプログラムでは、この問題が発生する可能性があります。alloc_fdtable() にチェックを追加し、リクエストされた割り当てサイズが INT_MAX を超えないようにすることで、これを修正します。これにより、カーネル警告をトリガーする代わりに -EMFILE で操作が失敗し、非実用的な >8GB メモリ割り当てリクエストが回避されます。 (CVE-2025-39756)

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

検出

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

medium Nessus プラグイン ID 264737

バージョン 1.11