Linux

Linuxカーネルにキルスイッチ案、未修正脆弱性に対応

Linuxカーネルに、危険なコード経路を走らせない「killswitch」が提案された。修正パッチを待つのではなく、脆弱な関数そのものを止める。Copy FailとDirty Fragの連発が、保守チームの発想を根本から動かしている。

情報の灯台

2026年5月12日 07:2600

カーネルが「直す」前に「止める」を選びはじめた

Linuxカーネルの保守チームが、脆弱な関数を実行時に無効化する仕組み「killswitch」を提案している。修正パッチが行き渡るまでの空白期間に、攻撃される前にその関数をシステムから消すためのものだ。提案者はNVIDIAのエンジニアでstable/LTSツリーの共同メンテナーを務めるサーシャ・レヴィン（Sasha Levin）。2026年5月7日にLKMLへ投稿され、翌日にはLWN.netが解説記事を出している。

ここで重要なのは、これが「修正」ではないという点だ。バグを直すわけではない。バグを呼ばないようにするだけだ。それでもメンテナーが提案に踏み切ったのは、ここ2週間のセキュリティ事案が、従来の「パッチ待ち」という前提を真正面から壊してしまったからだ。

「セキュリティ問題が公開されると、修正カーネルがビルドされ、配布され、再起動されるまで、フリート全体が露出したままになる。多くの場合、最もシンプルな緩和策は、バグのある関数を呼ばないことだ。killswitchはそれを提供する」

レヴィンはLKMLへの提案でこう書いた。脆弱性が見つかってから現場のサーバーに修正が届くまでの数日から数週間、システムは無防備のまま晒される。その「待ち時間」を埋めるための機構だ。

仕組みは「関数に値を返させて、本体を実行させない」

killswitchの動作はかなり単純だ。管理者がカーネルに関数名と返り値を渡す。すると、その関数を呼んだプログラムは指定された値だけを受け取り、関数の中身は一切実行されない。提案中の具体例ではこうなる。

echo "engage af_alg_sendmsg -1" > /sys/kernel/security/killswitch/control

これで、AF_ALG経由でデータを送ろうとするすべてのプログラムはエラーを返される。Copy Failが悪用していたAF_ALGのコード経路は、関数自体が実行されなくなるので攻撃者の足がかりが消える。効果は即時、全CPUコアに反映され、管理者が解除するか再起動するまで持続する。

ブートパラメータ版killswitch=fn1=val,fn2=val,...も用意されており、フリート全体に一括適用できる。レヴィンが「止めても困らない候補」として挙げているのは、AF_ALG、ksmbd、nftables、vsock、ax25といった、使われていないシステムでは丸ごと無効化しても実害が小さいサブシステム群だ。

「ほとんどのユーザーにとって、『このソケットファミリーが1日使えない』というコストは、修正が届くまで脆弱なカーネルを動かし続けるコストよりはるかに小さい」

レヴィン自身の言葉だが、ここには重要な思想転換がある。可用性より封じ込めを優先するという割り切りだ。サーバー運用の常識からすると、これは小さくない方針変更だ。

副作用と「キルスイッチを撃つキルスイッチ」議論

ただし、この機構は副作用も明確に持っている。killswitchを起動するとカーネルは「taint」状態（汚染）になる。新しいフラグHがbit 20に割り当てられ、一度立つと解除しても再起動まで消えない。以降のクラッシュレポートにはこの印が残り、メンテナーがバグ報告を受け取ったとき「このイメージは改変されている」と判断できる仕組みだ。

提案そのものに「これは footgun （自分の足を撃つ銃）だ。注意して使え」と書かれているあたり、レヴィン自身も危うさを認識している。LWNのコメント欄では、まさにこの危うさを巡って議論が起きた。

「rootがカーネル関数を上書きできる機能を追加するのは、非常に大きなハンマーだ。むしろrootができることを減らす方向に進むべきだ」

ある購読者はLWNのコメント欄でこう書いた。これに対しレヴィンは「livepatch、BPF、トレース基盤ですでに同じことができる。lockdownがそれらを縛る『キルスイッチ』だろう」と返している。すでにある危険機能の一つに過ぎないという主張だ。

議論の中でとくに不気味だったのは、コメント欄で出た「killswitchを永続的に無効化するkillswitch」という発想だった。攻撃者が永続的なroot侵入経路を確保していた場合、自分の侵入路を消されないようにkillswitch機能そのものをkillswitchで止めてしまえる、というシナリオが指摘されている。緊急対応用のツールが、攻撃者の防衛ツールに転用される可能性だ。

パッチ末尾に書かれていた共同執筆者

そして、この提案にはもう一つ目を引く点がある。パッチの末尾に書かれていたAssisted-by: Claude:claude-opus-4-7という1行だ。Anthropicの生成AI、Claude Opus 4.7 がこのコードの共同執筆者として明記されている。

これはレヴィン個人の趣向ではなく、Linuxカーネルの正式なコーディングアシスタント方針に沿った記述だ。AI支援で書かれたコードをどう帰属するかを定めたDocumentation/process/coding-assistants.rstは2025年末に成立し、今年リリースされたLinux 7.0でmainlineに入っている。レヴィンはその策定にも関わっている。グレッグ・クロー＝ハートマン（Greg Kroah-Hartman）がAIファジングツールをカーネルに当てて発見したバグの最初の対象は、奇しくもksmbd、今回killswitch候補として挙げられたサブシステムだった。

LWNのコメント欄では予想通り「LLMの男が書いた」と冷ややかな反応も出た。一方で、int killswitch_engage(const char *symbol, long retval)という関数シグネチャを見て「悪くない」と評価する開発者もいた。AIが書いたかどうかではなく、コードと議論の中身で評価される。カーネル開発の文化はまだ持ちこたえている、と言えるのかもしれない。

修正が間に合わない時代の応急処置

それでも、この提案が出てきたこと自体が時代の変化を映している。Copy Fail（CVE-2026-31431）の公開からDirty Frag（CVE-2026-43284/43500）の早期漏洩まで、ここ1か月でLinuxの脆弱性対応は「パッチと同時公開」という前提を二度続けて維持できなかった。決定論的なロジックバグでPoCも即座に出回るDirty Fragに至っては、各ディストリビューションのパッチが揃わないまま実環境への流出が始まっている。

killswitchはまだLKMLに投げられた1本のパッチで、mainlineにも、いかなるリリース版カーネルにも入っていない。今後のレビューサイクル次第で形が変わる可能性が高い。LWN上でも「800行以上かけて、既存のfault injection機構で済むことを再実装しているだけだ」という指摘が出ており、技術的な代替案も俎上に上がっている。

カーネルが「正しく動く」ことより「危ないことをやらない」ことを優先する設計を、上流が真剣に検討している。動かないことを選べる権限を、管理者の手に渡そうとしている。ソフトウェアサプライチェーンが「常にどこかが穴」という前提で動かなければならない時代に、上流の発想がここまで動いてきたという事実そのものに意味がある。

修正が間に合わない時代に、どこまで「動かさない」勇気を持てるか。今回のkillswitch提案が浮かび上がらせているのは、結局のところそういう問いだ。

参照元