Taichi Kanaya@Freelance Software Engineer

【Linuxカーネルに深刻度9.8（最大級）の脆弱性。WSL2とDockerの人はapt upgradeじゃ直りません】 脆弱性の対応、日々お疲れ様です Chromeに続いて、さらに来ました。今度はLinuxです ただ今回は「全員今すぐ」の話ではないので、先に落ち着いて読んでください 少し長いですが詳しくまとめたので、自分の環境の見出しだけでも読んでもらえると嬉しいです 何の話か CVE-2026-98432というLinuxカーネルのバグです（10月15日公開） 先日書いたChromeの大量修正にも関わっている、Anthropicの10月27日の発表（Claudeの未公開モデルが見つけた穴） その中のLinuxの1本です 2015年から入っていたバグなので、現役のLinuxはほぼ全部該当します CVEの記録上のスコアは10点満点の9.8です 中身 外から細工した接続要求を送りつけられるだけで、ログインも要らずに起きます 接続要求の処理が別のCPUで同時に走った時に、消したはずのメモリを読みに行くバグで、起きた時に一番ありそうなのはサーバーごと落ちる（クラッシュ）です IPv4の話で、IPv6は今回のバグの対象外です 条件が揃えば外からrootでコマンドを実行できるところまでAnthropicは実証したと発表しています ただ報道によるとその条件は「Multipath TCPで待ち受けているサーバー」で、これは複数回線を束ねる拡張で、アプリ側で明示的に使う設定が要るものです 普通の設定のWebサーバーがそのまま当てはまるかは、まだ分かりません 対象は、外に向けて待ち受けているサービスがある機械です Webだけでなく、SSHの22番を開けているだけで該当するので、開発用のVPSもほぼ全部です 逆に、外に向けて何も待ち受けていない機械には刺さる場所がありません AndroidやNAS、ルーター、ラズパイも中身はLinuxですが、考え方は同じで、外に待ち受けを開けていなければ急ぎではなく、修正はメーカー待ちです 温度感は配布元で割れています UbuntuはHigh Red Hatは現実的な被害は落ちるまでという見方でModerate、修正は今後の更新に回しています 悪用された報告は今のところ見当たりません なので「全員今すぐ」ではなく、自分がどのケースか見て、出た修正を当てる、で十分かなと思います クラウドやVPSで公開サーバーを動かしている人 配布元の修正が出たら当てて、再起動（カーネルは再起動して初めて効きます） Debianはもう出ています（12は6.1.190、13は6.12.113） Ubuntuは10月30日時点でも22.04、24.04とも作業中で、今apt upgradeしても当たるものはまだありません 出た時の番号は24.04が6.8.0-149、22.04が5.15.0-203の予定なので、uname -rがそれ以上になれば修正済みです 20.04以前は通常サポートが終わっているので、修正が来るとしてもUbuntu Pro（個人なら5台まで無料）に入っている人だけです Amazon Linux 2023は6.12系と6.18系のカーネルは修正済み、標準の6.1系とAmazon Linux 2はまだです Red Hat系（RHEL、AlmaLinux、Rocky）は配布元の判断で修正が後になるので、下のつなぎで待つ形です 修正が来るまでのつなぎ 公式の回避策は、UbuntuもRed HatもSUSEも出していません その上で、仕組みから言えることが2つあります 1つ目は露出を減らすこと SSHや管理画面は接続元を自分のIPに絞る CloudflareやALBのような前段を挟む場合は、本体側で前段のIP以外を遮断して初めて意味があります（NLBのようにL4で素通しするタイプは別） 2つ目はIPオプションを落とすこと バグが触るのは接続要求に付いていたIPオプションのメモリなので、IPオプション付きのTCPパケットを手前で落とせば、理屈上はこの経路に入りません（nftablesならip hdrlength > 5を条件にdrop） TCPだけに絞るのは、他のプロトコルには正規で付くことがあるからです ufwのような簡易ツールでは書けないので、nftablesかiptablesを直接触れる人向けで、自分の環境で試してからにしてください 有償のライブパッチ（KernelCareなど）はDebian 13向けが先に出ています Ubuntu ProのLivepatchは確認できていません WSL2の人 カーネルはUbuntuの中ではなく、Microsoftが配っています ここがややこしいのですが、Ubuntuの中でapt upgradeしても、カーネルは1ミリも変わりません 更新はPowerShellでwsl --update（かWindows Update） そのあとwsl --shutdownで一度止めると、次の起動から新しいカーネルになります Microsoftは修正入りのカーネル（6.18.58.1）をここ数日で公開していますが、wsl --updateで降ってくる版に入ったかはまだ確認できていません WSLの中でuname -rを打って、6.18.56以上なら修正済み、今配られている6.18.33系や、古いままの6.6系・5.15系なら未修正です （WSL1はLinuxカーネルを使っていないので関係ありません） Dockerの人 コンテナはホストのカーネルをそのまま使うので、コンテナの中で更新しても意味がありません LinuxのサーバーならホストのOSを更新 WindowsのDocker Desktopは標準のWSL2バックエンドならWSL2のカーネルで動いているので、上と同じwsl --update MacのDocker Desktopは自前のカーネルなので、Docker Desktop本体の更新です（修正入りの版が出たかは未確認） OrbStackやColima、Rancher Desktopも同じで、VMのカーネルを配っているのが誰かで決まります Hyper-VやVirtualBox、VMwareの仮想マシンの人 これだけはゲストの中でapt upgradeで合っています（配布元の修正が出てから） 自分のカーネルの番号はuname -rで出ます 修正済みは5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10以上です ただしこれは、WSL2やArch、Amazon Linuxのように上流の番号をそのまま使っている環境向けの目安です Ubuntu、Debian、Red Hat系は番号の付け方が違って上の番号とは比べられないので、配布元の案内（Ubuntuは上に書いた予定の番号）で見てください 自宅のWSL2や仮想マシンは、外から直接つながる構成（ブリッジ接続やポート開放）にしていなければ急ぎではありません ただ「apt upgradeしたから安心」は間違いなので、そこだけ覚えておいてください