Infinity CoreのLinuxカーネル6件はどのカーネル系列に影響するか
目次
TL;DR
影響 Linuxカーネル中核の6件。5件は一般ユーザーからrootへ上がるローカル権限昇格で、コンテナ脱出にも使える(うちSchedulerは特定の構成のときだけ)
範囲 上流での導入時期がCVEごとに違う。Debian 12と13、Ubuntu 24.04の標準カーネルはTimerだけ(24.04の7.0系HWEカーネルはMMも)、Ubuntu 26.04は4件、RHELは機能のバックポートでSignalやFutexも対象
対応 ディストリの修正済みカーネルへ更新して再起動。中核機能なのでモジュール無効化のような暫定策はない。Schedulerだけはビルド設定と実行時の条件がそろわないと脆弱な処理を通らない
Infinity Coreは、Dirty Fragを見つけたHyunwoo Kim(V4bel)が公開したLinuxカーネルの脆弱性6件の総称だ。
linux-distrosメーリングリストとのエンバーゴ(修正がそろうまで公開を待つ取り決め)が明けたあと、日本時間10月17日午前1時にoss-securityへの投稿とGitHubのInfinityCoreが出た。
以前扱ったCopy FailやDirty Fragは、暗号APIやIPsecといった周辺機能の経路を使っていた。
Infinity CoreのREADMEは、ネットワーク、ソケット、perf、BPFのようにバグの多い領域と、ユーザー名前空間がないと発火しないバグを最初から対象外にしている。
残ったのはタイマー、シグナル、メモリ管理、futex、スケジューラ、スラブアロケータで、どれもカーネル本体の機能だ。
6件の一覧と導入時期
各CVEの導入版と修正版は、LinuxカーネルのCVE番号を発行しているLinux kernel CVE Teamの告知から拾った。
Linuxカーネルは、新機能が入るメインライン(上流)と、6.6や6.12のように修正だけを受け取り続ける複数の安定版系列が並行している。
上流で入った変更を古い系列へ移植することをバックポートと呼び、修正だけでなくバグも同じ経路で古い系列に入ることがある。
表の「導入」はバグの入ったコミットが最初に含まれたメインラインの版で、「上流の修正版」は安定版系列ごとの修正リリースだ。
| CVE | 対象 | 種類 | 実証された影響 | 導入 | 上流の修正版 |
|---|---|---|---|---|---|
| CVE-2026-98260 | Timer | UAF | root昇格、コンテナ脱出、Android root | 5.7 | 6.6.158、6.12.112、6.18.54、7.2.8 |
| CVE-2026-98256 | Signal | UAF | root昇格、コンテナ脱出 | 6.15 | 6.18.54、7.2.8 |
| CVE-2026-89754 | MM | 範囲外書き込み | root昇格、コンテナ脱出 | 7.0 | 6.18.50、7.2.4 |
| CVE-2026-80775 | Futex | UAF | root昇格、コンテナ脱出 | 6.17 | 6.18.47、7.1.11、7.2.1 |
| CVE-2026-98385 | Scheduler | UAF | 特定構成でroot昇格、コンテナ脱出 | 7.2 | 7.2.9 |
| CVE-2026-97941 | SLAB | リスト破損 | カーネルパニック | 7.2 | 7.2.7 |
MMは7.0で入ったバグだが、安定版の6.18系では6.18.21から6.18.49まで、6.19系では6.19.11以降にもバックポートで入っている。
UAF(Use-After-Free)は、解放済みのメモリを指したままのポインタを後から使ってしまうバグで、解放された領域に攻撃者が別のデータを置けると、カーネルがそのデータを正規の構造体として読み書きし、権限の書き換えにつながる。
CVE番号の告知はoss-securityへの投稿より前に出ている。
Futexは9月4日、SLABは9月25日、TimerとSignalは10月6日、Schedulerは10月12日で、エンバーゴ中は修正コミットとCVEだけが先に公開され、悪用の詳細は伏せられていた。
導入の列を上流のバージョンで比べると、古い系列から影響するのはTimerだけだ。
ただし配布元が新しい機能を古い系列へバックポートしていると、この表より古いカーネルにもバグが入る。
SchedulerとSLABは上流では7.2で入ったコードで、上流の表どおりなら、7.2系を使うArch Linuxのようなローリングリリースか、自前で新しいカーネルを入れている環境が対象になる。
READMEのテスト環境も、Timer、Signal、MM、Futexの4件がUbuntu 26.04の 7.0.0-30-generic、SchedulerとSLABがArch Linuxの 7.2.4-arch1-2 だ。
主要ディストリの状況
各ディストリのセキュリティトラッカーを10月22日に確認した。
カーネルのバージョン番号は上流と一致しないので、表の判定は各配布元のトラッカーの記載どおりにした。
Ubuntuの「HWEカーネル」は、新しいハードウェア向けにLTSへ後から提供されるカーネルで、標準カーネルより新しい系列を使うぶん影響するCVEも違う。
| ディストリ | 影響するCVE | 10月22日時点の状態 |
|---|---|---|
| Ubuntu 26.04 LTS | Timer、Signal、MM、Futex | すべて修正作業中で未提供 |
| Ubuntu 24.04 LTS | Timer(7.0系HWEカーネルではMMも) | 修正作業中で未提供 |
| Ubuntu 22.04 LTS | Timer | 未提供 |
| Ubuntu 20.04 LTS | 標準の5.4系はなし。5.15系HWEカーネルはTimer | 5.15系HWEカーネルは未提供 |
| Ubuntu 18.04 LTS以前 | なし | 影響なし |
| Debian 13 trixie | Timer | 6.12.113-1で修正済み(DSA-6568-1) |
| Debian 12 bookworm | Timer | 6.1.190-1で修正済み(DLA-4841-1) |
| RHEL 9 | Timer、Futex | kernel はTimerが5.14.0-687.59.1.el9_8(RHSA-2026:86033)、Futexが5.14.0-687.54.1.el9_8で修正済み。kernel-rt はTimerとFutexが未修正 |
| RHEL 10 | Timer、Signal、Futex | TimerとSignalは6.12.0-211.67.1.el10_2で修正済み(RHSA-2026:85321)。Futexは未修正 |
| RHEL 7、8 | なし | 影響なし |
DSA・DLAはDebian、RHSAはRed Hatのセキュリティアドバイザリ(修正パッケージの公開告知)の番号だ。
kernel-rt はRHELのリアルタイム処理向けカーネルで、通常の kernel とは別パッケージとして修正状況が分かれている。
UbuntuはCVE-2026-98260、CVE-2026-98256、CVE-2026-89754、CVE-2026-80775の各ページで、26.04 LTSの本体カーネル linux がいずれも「Vulnerable, work in progress」になっている。
PoC(脆弱性を実際に突けることを示す検証用コード)のテスト環境も、READMEではUbuntu 26.04の修正前のカーネル 7.0.0-30-generic になっている。
24.04 LTSは標準の6.8系カーネルならTimerだけだが、7.0系のHWEカーネルを入れているとMMも対象に入る。
Debianのセキュリティトラッカーでは、bookwormとtrixieのTimerは修正済みで、Signal、MM、Futexは「Vulnerable code not present」として対象外だ。
上流のCVE告知には6.1系の修正版が載っていないが、Debianはbookworm向けに独自に修正を取り込んでいる。
Red HatはCVE-2026-98260、CVE-2026-98256、CVE-2026-80775の各ページで確認した。
MM、Scheduler、SLABは、Red HatのデータではRHEL 7から10まで影響なしだ。
Futexのバグは上流では6.17で入ったものなのに、RHEL 9の 5.14.0 系カーネルが影響ありとされている。
RHEL 10の 6.12.0 系も、上流では6.15で入ったSignalと6.17で入ったFutexの対象になっている。
Red Hatが新しい機能を自社カーネルへバックポートした際に、脆弱なコードも一緒に入ったと考えられる。
uname -r の数字を上流の表と比べても、影響の有無も修正の有無も判定できない。
PoCの中身
READMEに書き換え先まで書かれているのは、MM、Futex、Schedulerの3件だ。
MMはプロセスの認証情報を直接書き換え、FutexとSchedulerはsetuidバイナリ(実行したユーザーに関係なく所有者、多くはrootの権限で動くプログラム)のページキャッシュを書き換える。
ページキャッシュは、ディスク上のファイルの内容をLinuxがメモリ上に保持しているコピーで、ここを書き換えると次にそのプログラムを実行したときに改変後の内容が実行される。
| CVE | PoCがrootを得る方法 |
|---|---|
| Timer | 一般ユーザーからUbuntu 26.04でrootシェル。Galaxy S26 Ultraでは一般アプリのサンドボックス untrusted_app からroot |
| Signal | 解放済みのシグナルキュー項目が再利用されたかを判定し、細工したキューを取り出す処理でrootシェル |
| MM | mincore() の一時バッファの直後に struct cred を置き、UIDとGIDを0に書き換える |
| Futex | 解放済みのハッシュをpipeのリングで取り直し、pipe_buffer のフラグを変えて /usr/bin/passwd のページキャッシュを上書き |
| Scheduler | 古い統計の書き込みでfutexハッシュの参照カウンタを壊し、Futexと同じ手順で /usr/bin/newgrp のページキャッシュを上書き |
struct cred はプロセスのUIDやGIDを持つカーネル内の構造体で、ここが0になればそのプロセスはrootとして扱われる。
FutexとSchedulerは最後に、Dirty Pipeと同じく pipe_buffer のフラグを書き換えてページキャッシュへ書き込む。
この2件はバグ自体は中核機能のUAFでも、rootを取る最後の手順はこれまでのページキャッシュ汚染と同じだ。
Timer
非リーダースレッド(プロセス内で最初に作られたスレッド以外)が exec() すると、de_thread() がそのスレッドに元のリーダーのPIDを引き継がせる。
このあと exec() が失敗してタスクが終了すると、スレッド単位のCPUタイマーは解放されるのに、そのノードは生きているタスクのタイマーキューに残る。
後でタスクを片付ける処理がこのノードをもう一度操作し、解放済みメモリを書き換えてしまう。
修正では、POSIXタイマーの後片付けを de_thread() の直後へ移し、exec() が失敗して終了する前に済ませるようにした。
バグの入ったコミットは5.7のもので、6件の中でいちばん古い。
Galaxy S26 Ultraでの権限昇格はAndroid向けエクスプロイト(攻撃コード)の公開を保留していて、READMEにはファイルのハッシュ値だけが載っている。
Galaxy側の修正が出るか、第三者が別にエクスプロイトを公開した時点で出すとしている。
Signal
これも非リーダースレッドの exec() が起点になる。
終了しかけた古いリーダーの保留シグナルのリストをロックなしで片付ける処理と、引き継いだPIDをたどって新しいリーダーのキューへシグナルをつなぐ処理が、同じ sigqueue を同時に操作する。
修正では、終了処理中のタスクへのプライベートシグナルのキューイングを禁止し、exit_signals() の中で保留キューをすぐ空にする。
MM
mincore() は、指定したメモリ範囲のページが物理メモリ上にあるかを1ページ1バイトで返すシステムコールだ。
madvise(MADV_DONTNEED) と競合してページテーブルが消えると、下位の走査処理が「再試行」の状態を戻さずに返り、上位がそれを同じ範囲のやり直しと解釈する。
結果を書く位置はすでに進んでいるので、1ページ分の一時バッファを越えて隣のカーネルメモリへ書き込む。
Futex
futexはユーザー空間のロックを実装するためのカーネル機能で、プロセスごとの専用ハッシュの大きさを prctl() で設定できる。
入れ子の vfork() で同じメモリ空間を共有する2つのタスクが、最初の参照カウンタを同時に割り当てると、先に書いた側のカウンタが追跡から外れる。
使用中のハッシュが解放され、残ったポインタから解放済みメモリへ書き込める。
Scheduler
7.2で入ったスケジューラのキャッシュ統計は、統計をタスクのメモリ空間(mm_struct)に埋め込んでいた。
別のCPUで exec() がメモリ空間を差し替えて古い統計を解放したあとも、スケジューラが保存しておいたアドレスへ書き続ける。
READMEによると、脆弱な経路を通るには次の条件がすべて必要だ。
| 条件 | 内容 |
|---|---|
| ビルド設定 | CONFIG_SCHED_CACHE=y |
| 実行時 | sched_cache_active が有効 |
| CPU構成 | LLC(最終段キャッシュ)を共有するドメインに複数のCPUがあり、その上により広い親ドメインがある |
| sysctl | sysctl_sched_cache_user が0以外 |
公開PoCは、CPU 0と1、CPU 2と3がそれぞれLLCを共有する4 vCPU構成を想定している。
SLAB
READMEの「SLAB」はスラブアロケータの分類名で、現在のLinuxで使われている実装がSLUBだ。
SLUBはカーネル内の小さなオブジェクトを割り当てるメモリアロケータで、同じ大きさのオブジェクトをスラブと呼ぶページ単位のまとまりから切り出して渡す。
7.2で入った楽観的な返却処理が、cmpxchg でfreelistとカウンタだけを比べていたため、その間に別のCPUがオブジェクトを解放して再確保し、スラブが同じ状態へ戻ってきた変化を見落とす(ABA問題)。
同じリストノードを2回つないでしまい、リストが壊れる。
公開されているのはSystem Vメッセージで競合を繰り返し起こしてカーネルパニックさせるコードだけで、root昇格までつないだPoCはない。
コンテナとAndroidへの影響
コンテナはホストとカーネルを共有するので、カーネルの権限昇格はそのままホスト側の権限になりうる。
READMEはSLAB以外の5件でコンテナ脱出を実証済みとしている。
Kubernetesのワーカーノード、CIのビルド用ランナー、複数の利用者がログインする共用サーバーのように、他人の書いたコードがホストと同じカーネルの上で動く環境が該当する。
一方で、6件ともローカルでコードを動かせることが前提だ。
Webアプリなどの別の脆弱性でサーバー上のコードを実行できた攻撃者が、権限を上げるために使うことになる。
10月21日版のCISA KEVカタログ(実際の悪用が確認された脆弱性の一覧)に6件は入っていない。
Androidで実証されたのはTimerだけで、Galaxy S26 Ultraの一般アプリ用の権限から追加権限なしでrootを取ったと書かれている。
ほかの機種やほかのCVEがAndroidで通るかは、READMEには書かれていない。
暫定策と更新後の確認
Dirty FragではESPやRxRPCのモジュールをロード禁止にする暫定策があった。
Infinity Coreの対象はタイマー、シグナル、futex、メモリ管理といった本体の機能なので、同じように無効化できない。
BPFやユーザー名前空間を無効化している環境でも、READMEが最初からそれらを使わないバグを選んでいる以上、対策にならない。
設定で外せるのはSchedulerだけで、CONFIG_SCHED_CACHE を無効にしたビルドや、前述の実行時条件を満たさない構成では脆弱な経路を通らない。
SchedulerとSLABは、そもそも7.2より前のカーネルには入っていない。
それ以外は、配布元の修正済みカーネルを入れて再起動するのが対応になる。
パッケージを更新しても古いカーネルで動き続けていれば意味がないので、再起動後に uname -r で実際に起動したカーネルを確かめる。