【ITニュース解説】Six Linux kernel reports, one public root exploit, and no CVE to track them by

Linuxカーネルは、コンピューターシステムの根幹を支える非常に重要なソフトウェアだ。そのカーネルにセキュリティ上の欠陥、すなわち「脆弱性」が見つかると、システム全体の安全性が危機に瀕する。今回のニュースは、そんなLinuxカーネルの脆弱性に関する報告と、その対応を巡る具体的な課題について深く掘り下げている。

セキュリティ研究機関であるゼロデイイニシアティブ（ZDI）は、2026年10月20日から21日にかけて、Linuxカーネルにおける六つの脆弱性に関する報告を公開した。通常、このような脆弱性には「CVE」（共通脆弱性識別子）という世界共通の識別番号が付与される。CVEは、特定の脆弱性を一意に特定し、その情報交換を効率的にするための「脆弱性の住所」のような役割を果たす。CVE番号があれば、システム管理者は脆弱性スキャナーを用いてシステムを自動的にチェックしたり、ベンダーが提供する修正パッチやセキュリティアドバイザリ（注意喚起）を容易に探し出したりできる。しかし、今回ZDIが報告した六つの脆弱性については、ニュース記事の分析時点ではまだ一つもCVE番号が割り当てられていなかった。

CVE番号がないという状況は、脆弱性管理と対応において極めて大きな問題を引き起こす。CVE番号があれば、多くのツールや情報源がそれを基準に動くため、脆弱性の発見から修正、そしてその適用状況の追跡までを一貫して行える。しかし、それが欠けている場合、得られる情報はZDIが独自に付与した候補番号（ZDI-CAN-XXXXXのような形式）と、脆弱性の簡単な説明、そして開発者向けのメーリングリストのスレッドといった断片的なものに限られる。これは、システム運用者が自分のシステムにどのような脆弱性が存在し、どのように対処すべきかを判断する上で、大きな障壁となるのだ。

特に深刻なのは、六つの脆弱性のうちの一つ、ZDI-CAN-33367に関する状況である。この脆弱性は、Linuxのネットワークスタックに存在する「ローカル権限昇格」と呼ばれる種類の欠陥で、ZDIによる深刻度評価は7.8点とされている。ローカル権限昇格とは、システム上で低い権限しか持たない一般ユーザーが、特定の脆弱性を悪用することで、システム管理者（ルート）のような高い権限を不正に取得できてしまうことだ。この脆弱性を利用すると、本来は読み取り専用であるはずのファイルのメモリ上の内容を、権限のないユーザーが書き換えてしまう可能性もあるという。さらに懸念されるのは、このZDI-CAN-33367について、脆弱性報告からわずか数日後の10月24日には、実際にルート権限を奪取できる動作する攻撃コード（Proof of Concept、略してPoC）が公開されていたことだ。PoCは、脆弱性が実際に悪用可能であることを実証するために作成されたプログラムであり、これが公開されると、悪意のある攻撃者がそれを参考にして実際の攻撃に利用するリスクが飛躍的に高まる。

このZDI-CAN-33367の危険性は、その影響範囲の広さからも理解できる。TuxCareというセキュリティ企業が実施した検証により、AlmaLinux 8から10、CloudLinux 9と10、Debian 12と13、そしてUbuntu 24.04と26.04といった、多くの企業や組織、個人が利用している主要なLinuxディストリビューションの複数バージョンで、このPoCを用いて実際にルートシェル（システムを完全に制御できる状態）が取得できることが確認された。これは、単に理論上の脆弱性ではなく、現実世界でシステムが乗っ取られる危険性が非常に高いことを明確に示している。

この脆弱性への対策として、Sysdigというセキュリティ企業は「unprivileged user namespaces」の制限を提案している。user namespacesは、Linuxの機能の一つで、ユーザーが独自のID空間を持つ隔離された環境（名前空間）を生成し、その中でroot権限なしにコンテナのような分離されたプロセスを実行できるものだ。これを制限することは、セキュリティを強化する有効な手段となりうるが、Sysdigは同時に、この対策が「rootless containers」（ルート権限を使わずにコンテナを運用する技術）といった、現代の多くの開発チームが採用している効率的なデプロイパターンを阻害する可能性も指摘している。セキュリティ強化と運用上の利便性の間で、適切なバランスを見つける必要が出てくるわけだ。

また、今回の報告には、深刻度9.0と特に高い評価を受けた二つの脆弱性、ZDI-CAN-33774とZDI-CAN-33549も含まれている。これらは両方とも、Linuxカーネルに実装されているSMB（Server Message Block）サーバーである「ksmbd」に関するものだ。SMBは主にWindows環境でファイル共有などに使われるプロトコルで、Linuxカーネルにもksmbdとして組み込まれることがある。ZDI-CAN-33774は、リモートからのアクセスが可能で、しかも事前認証なしで悪用できるという極めて危険な性質を持つ。これにより、攻撃者はネットワーク経由で簡単にシステムに侵入し、カーネルメモリの情報を盗み出したり、システムをクラッシュさせたりする可能性がある。もう一つのZDI-CAN-33549は、SMB Direct（RDMAインターフェース）と書き込み可能な共有が必要という、より限定的な前提条件があるため、悪用される機会は少ないかもしれないが、それでも高いリスクを伴う。

ksmbd関連の脆弱性に対する対策として、Sysdigは、ksmbdを必要としないシステムではこれを「アンロード」（停止）することを推奨している。そして、ksmbdをどうしても利用する必要があるシステムでは、SMBが使用するポート445へのアクセスを、信頼できる特定のネットワークからの接続に限定するよう助言している。これは、不要なサービスは停止し、必要なサービスであってもそのアクセス範囲を最小限に抑えるという、セキュリティ対策の基本的な考え方に基づいている。

その他の脆弱性として、ZDI-CAN-34068は、カーネルのVMwareグラフィックスドライバーにおけるローカル権限昇格の脆弱性で、深刻度は8.8だ。この脆弱性については、分析時点ではまだ修正パッチが提供されておらず、脆弱性のタイトルしか公開されていなかったため、詳細な情報は不足している。さらに、ZDI-CAN-34076はNVMeターゲットにおける情報漏洩、ZDI-CAN-32005はConnManネットワークマネージャーにおけるユーザー空間のスタックオーバーフローに関するものだ。NVMeターゲットやConnManは、厳密にはLinuxカーネル本体ではなく、周辺のコンポーネントに分類されるため、これらの脆弱性に対する修正の責任者は、カーネルの主要開発チームとは異なる場合がある点も理解しておくべきだ。

今回のケースのように、CVE番号という統一された識別子がない状況で、システム運用者はどのように脆弱性への対応を優先順位付けるべきだろうか。Sysdigは、脆弱性の深刻度を示すCVSSスコアだけで判断するのではなく、「実際に自分のシステムで稼働しているコンポーネントに基づいて優先順位を付ける」という実践的なアプローチを推奨している。例えば、もし自分のシステムでksmbdを使用していないのであれば、たとえksmbd関連の脆弱性のCVSSスコアが9.0と非常に高くても、そのシステムは影響を受けないため、優先順位は低くなる。一方で、たとえCVSSスコアが7.8と比較的低くても、unprivileged user namespacesを有効にしたカーネルでコンテナを運用しているシステムは、ZDI-CAN-33367の影響を受ける可能性が非常に高いため、早急な対応が必要となる。このように、自社のシステム構成、つまり「コンポーネントのインベントリ（在庫管理）」を正確に把握することが、CVEがない状況でのリスク評価と対応計画において、極めて重要な役割を果たすのだ。

また、CVE情報だけでは見落とされがちな、パッチの適用状況も重要な判断基準となる。ニュース記事の分析時点では、AlmaLinuxの一部のバージョンではテスト中のカーネルに修正が含まれていたものの、本番環境向けの公式パッケージとしてはまだリリースされていなかった。このような状況では、仮にCVE番号が割り当てられていたとしても、修正済みバージョンを認識する脆弱性スキャナーは、本番環境のシステムを「影響なし」と誤って報告してしまう可能性がある。しかし実際には、修正版が本番環境に適用されるまでの間、そのシステムは脆弱な状態に置かれている。

今回の報告を受けて、システム運用者が記録すべき情報は何か。CVE番号が割り当てられるまでの間、ZDIの候補番号（例：ZDI-CAN-33367）が唯一の安定した識別子となるため、これをセキュリティチケットなどに必ず記録しておくべきだ。加えて、影響を受けるコンポーネント、各Linuxディストリビューションでのテスト結果、そしてシステムに適用した緩和策や対応状況も、詳細に記録することが求められる。これにより、後にCVE番号が発行され、それに関連する公式のアドバイザリが公開された際に、過去の対応記録と容易に紐付けられるようになる。

今回の件で特に強調されるべき点は、ZDI-CAN-33367の脆弱性に対しては、すでに公開されたエクスプロイトが存在し、実際にルートシェルが奪取できる状況にあることだ。これは、脆弱性が単に発見されただけでなく、それが現実に悪用され、システムが危険に晒される可能性が目の前にあることを意味する。記事に記載された特定のLinuxディストリビューションを使用しているシステムは、直ちに脆弱性の有無をテストし、確認された場合には速やかに修正対応を行う必要がある。この状況は「待っていてはならない」という極めて高い緊急性をはらんでいるのだ。

システムエンジニアを目指す皆さんにとって、このようなセキュリティのニュースは、単なる情報収集に留まらず、将来、システムの運用や開発に携わる上で直面する現実的な課題を教えてくれる。脆弱性情報は常に変化し、その管理や対応には、技術的な知識だけでなく、状況を正確に判断し、リスクを最小限に抑えるための総合的な視点が不可欠となる。CVE番号のような標準的な識別子が機能しない場合でも、どのようにしてシステムの安全性を確保し、潜在的な脅威から守るか。今回のようなケースは、その難しさと、それに対処するための実践的なアプローチを学ぶ貴重な機会となるだろう。常に最新の情報を追跡し、自社のシステム構成を正確に把握し、迅速かつ的確な対応を心がけることが、安全なシステム運用には不可欠である。