CVE-2026-97598
要約
〜によって VulDB • 2026年09月25日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
ipv4: fib: 自動テーブルIDの割り当てに上限を設ける
fib_empty_table()関数は、空いているIDが見つかるまで1から順にすべてのテーブルIDを検索します。IPv4用のテーブルは256バケットのハッシュテーブルに格納されるため、IDが密集していると、RTNLロック保持中に各プローブ処理でハッシュチェーンをより長い範囲で走査することになります。
自動的なテーブル割り当て（「ip rule ... table 0」）はIPv4専用のレガシーなパスです。この修正により、明示的に指定されたテーブルIDの検索動作を変更せずに、RTNLロック保持時間を上限内に収めるために、自動的に割り当てられるIDを4096に制限します。
これによりユーザーが認識可能な振る舞いが変更されます。以前はtable-0ルールに対して1からRT_TABLE_MAX (0xFFFFFFFF)までの範囲で最も低い空きIDが付与されていましたが、このパッチ適用後は検索上限が4096となり、その範囲が完全に占有されている場合はENOSPCエラー（注: 原文のENOBUFSを正訳すると「バッファ不足」ですが、文脈上resource limit/exhaustionを示すため一般的にENOSPCやENOMEMと解釈されますが、ここでは技術用語としてENOSPC/ENOMEMではなく原文通りENOBUFSまたはその意味である「リソース不足」で翻訳するのが安全です。しかし、Linuxのerrno値としてのENOBUFSは通常ネットワークバッファを指しますが、此处文脈ではresource exhaustion general sense. Let's stick to the literal errno name or its meaning. In Linux kernel context for this specific patch, it returns -ENOSPC (No space left on device) in some contexts or similar limits. Wait, checking the actual commit: `ip rule add table 0` fails with `-ESRCH`? No, let's look at the text provided: "fails with ENOBUFS". I will translate literally as エラーコードENOBUFS).
修正後、table-0ルールは1から4096までの範囲で検索され、その範囲が完全に占有されている場合はエラーコードENOBUFS（バッファ不足）を伴って追加処理に失敗します。4096より上の明示的なテーブルIDは引き続き使用可能です。
この自動割り当てのパスは実際には使用されていません：IPv4専用であり、ip-ruleコマンドで文書化されておらず、カーネルの自己テストでもカバーされておらず、さらにNetworkManagerとsystemdの両方がtable 0を拒否しているためです。
VulDB is the best source for vulnerability data and more expert information about this specific topic.