ハクソク

世界を動かす技術を、日本語で。

CopyFailはGentoo開発者に開示されなかった

4時間前原文(www.openwall.com)

概要

  • Linuxカーネルに深刻なローカル権限昇格脆弱性（CVE-2026-31431）が発見
  • 影響範囲はバージョン4.14以降の多くのカーネル
  • 修正済みバージョンは6.18.22、6.19.12、7.0
  • 一部のLTS（長期サポート）カーネルでは未修正
  • 回避策パッチが一部で提供

CVE-2026-31431: Linuxカーネルのローカル権限昇格脆弱性

  • CVE-2026-31431は、Linuxカーネルに存在する深刻なローカル権限昇格（LPE）脆弱性
  • 2017年のコミット（72548b093ee38a6d4f2a19e6ef1948ae05c181f7）で導入
  • 修正コミットは以下の通り
    • 6.18.22：fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8
    • 6.19.12：ce42ee423e58dffa5ec03524054c9d8bfd4f6237
    • 7.0：a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
  • 修正済みバージョン：6.18.22、6.19.12、7.0
  • **LTSカーネル（6.12、6.6、6.1、5.15、5.10）**では2026年4月時点で未修正

影響範囲と対応状況

  • 影響範囲はバージョン4.14以降の多くのカーネル
  • LTSカーネルへのバックポートは困難
    • API変更が多く、単純な適用が不可
    • 安全性確保のため即時リリースは見送り
  • 一時的な回避策パッチが一部で提供
    • 例：「0001-crypto-disable-authencesn-module-for-CVE-2026-31431.patch」

脆弱性の重大性

  • 「make-me-root」型の深刻な脆弱性
    • 攻撃者がローカルからroot権限を取得可能
  • 2026年時点で最悪レベルのカーネル脆弱性
  • クラウド環境やサーバーでの影響が特に大きい

情報公開とコミュニティ対応

  • **embargo（公開制限）**が早期に解除された可能性
  • **linux-distros ML（メーリングリスト）**経由での事前通知はなし
  • コミュニティによる迅速な議論・対応
  • AIによるノイズ増加も指摘される中、開発者の負担増

参考リンク・リソース

対策と推奨事項

  • 該当カーネル利用者は速やかに修正版へアップデートを推奨
  • LTSカーネル利用者はディストリビューションのアナウンスや回避策パッチの適用を検討
  • 脆弱性情報のウォッチとコミュニティの最新情報への注意

まとめ

  • Linuxカーネルの運用管理者は、今回の脆弱性に特に注意
  • セキュリティパッチの適用と情報収集が重要
  • 長期運用環境では追加の回避策も検討

Hackerたちの意見

ちなみに、リンク先の投稿の著者であるサム・ジェームズはGentooの開発者です。さて、これはひどい事態ですね。修正が配布される前に、世界にこの脆弱性を共有するのは非常に無責任です。どれだけの共有ホスティングプロバイダーがハッキングされたか分かりませんし、カーネルセキュリティチームと配布メンテナの間にコミュニケーションがないのも心配です。前者が後者に通知するのが理想ですが、どうやら脆弱性を見つけた人の責任みたいです。
└
人々が正しい行動をすることを期待するのが根本的な問題ですね。すべての脆弱性がプライベートに開示されることを期待するなんて、なぜそんなことを？実際にそうするインセンティブはほとんどありません。これを防ぐためにどんなシステムが必要かは正直分かりませんが、常に人々が正しいことをすることを期待するのはファンタジーレベルの考えです。開示者たちも自分たちが正しいことをしていると思っていたでしょうから、そこに頼るのは良くないことですね。追記：スペル/文法の修正。
└
この開示はセキュリティよりもマーケティングに関するものだったね。開示ページから: > あなたのソフトウェアはAI時代に安全ですか？ > コピー失敗は、Linuxの暗号/サブシステムに対して約1時間のスキャン時間でXint Codeによって明らかにされた。 [...] > [Xint Codeを試してみて] もっと混乱があれば、彼らの製品がさらに魅力的に見えるよね。
└
> 修正が出る前に世界にエクスプロイトを共有するのは、非常に無責任だった。これは明らかにXint Codeを宣伝するためのマーケティングのスタントだよ。俺は絶対にXint Codeを使わないし、みんなにも使わないように勧める。そこにいる人たちへ: 15分の名声を楽しんでね、これが逆効果になることを願ってる。
└
どれだけの攻撃者がこの脆弱性を見つけて、研究が見つける前にすでに使っていたのか、誰がわかるんだろう？
└
Linuxカーネルはセキュリティの境界として使えないから、「共有ホスティング」をしたい人は、gVisorやfirecracker VMみたいな別のものを使う必要がある。セキュリティの境界として使っている重要なシステムはAndroidだけで、APKにはユーザーの承認が必要だし、厳しいSELinuxやseccompポリシー、GrapheneOSの強化があるから、今回はその対策がうまくいったみたいだね（https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...）。
└
まあ、これは大惨事だね。配布元が修正を出す前に、世界にその脆弱性を共有するのは非常に無責任だった。何十億も稼いでる企業が、重要な脆弱性の報告に対してほんの少しの報酬しか払わないのが原因かもね…。
└
> 非常に無責任だった。ユーザーとして、管理者として、私は同意しないな。「責任ある」開示って、まるで「セキュア」ブートみたいに、企業や財団の中間業者のための評判管理のためのものだと思う。彼らは私のコンピュータが脆弱であることには興味がないけど、「RHELが脆弱だ」とか「Ubuntuが脆弱だ」と言われることには気を使ってる。脆弱性はどちらにしても存在するし、修正に驚かされるよりも、リスクを最小限に抑えるために知るチャンスがある方がいい。私にとって、即時の公開開示が無責任でない唯一の選択肢だよ。
└
開示のメカニズムについて立場を取らずに言うと、これでハッキングされたホスティングプロバイダーは、すでに負けるつもりでやってたんだよね。信頼できないテナントのワークロードを単一の共有カーネルの下で動かすのはダメだよ。カーネルのLPEは珍しくないし、これは特にシンプルでポータブルなものだったけど、根本的な能力はCNEのコモディティだよ。
└
> まあ、これは大惨事だね。配布元が修正を出す前に、世界にその脆弱性を共有するのは非常に無責任だった。どれだけの共有ホスティングプロバイダーがこれでハッキングされたか分からない。ソフトウェアセキュリティに対して私たちがどれだけ注意を払っていないかが無責任かもしれない。もしかしたら、あらゆる種類のソフトウェア開発者は、全く新機能を開発するのではなく、30年分の技術的負債を解消するために1年を費やすべきかもね。そう聞くと革命的に思えるけど、AIエージェントでこの規模のカーネルバグを見つけるのが簡単な時代に、代替案は見当たらないよ。
下のBleeping Computerのリンクには、パッチが準備されるまでの潜在的な対策が載っています。 https://www.bleepingcomputer.com/news/security/new-linux-cop...
└
この回避策は、影響を受けたコードがモジュールとしてコンパイルされたカーネルにのみ適用されます。RHEL、Fedora、Gentoo（私たちは修正されたFedoraの設定を使っています）は、すべてこれを直接ビルドするように設定されています。パッチや設定変更がない限り（サムがGentooで示唆していたように）、これらの配布は脆弱なままです。
└
潜在的な対策は、影響を受けたコードがモジュールではなく、静的にコンパイルされているため、RedHatやその派生版では機能しません。
> Linuxカーネルの脆弱性については、報告者がlinux-distros MLに持ち込まない限り、配布に事前通知はありません。なぜ報告者が配布と連絡を取る責任があると暗示するのでしょうか？それはLinuxプロジェクトに対する高い理解度を前提にしているように思えます。脆弱性の報告者が、Linuxカーネルのすべての下流の利用者と直接やり取りする責任を負うべきではありません。そこに何か制限があるのでしょうか？報告者はLinuxを使っているすべてのデバイスメーカーとも直接話すべきなのでしょうか？私の意見では、報告者は責任を持ってLinuxに開示し、パッチが出るのを待つことで十分すぎることをしました。Linuxプロジェクト内にセキュリティ脆弱性に対する権限と責任を持つ人がいるはずです。彼らが下流の配布に通知するべきだと思いますが…。
└
確かに、これは「必須」ではないかもしれませんが、報告者が安全な修正よりも名声を優先したせいで、今みんながもっと苦しんでいます。
└
報告者はUbuntu、RedHat、Amazon、SUSEを明示的に呼び出すウェブサイトを作ったのに、彼らには通知しなかったんですか？それが合理的だと思いますか？彼らがそれらの配布がカーネルチームの下流にあることを知らなかった可能性があると思いますか？
└
記者は、Ubuntu/RHEL/SUSEの特定のディストリビューションについて、ウェブサイトで確認して言及する時間を取ったみたいだね。少なくともその辺のセキュリティチームに報告するのが責任だと思ったんだけど。
└
こんなセキュリティ問題をLinuxディストリビューションに報告する方法を見つけるのは簡単だよ。グーグル検索: https://share.google/aimode/eihDKXZJy94Z5lC1p こんなことを考えずに、みんなや隣人をこのエクスプロイトにさらすなんて、俺には理解できない。これは一部の法律では重罪になるんじゃないかな、当然だけど。
└
特に、報告者が最初にディストリビューションチームに通知しないように明示的に求められてるからね。 「そのため、カーネルセキュリティチームは、潜在的なセキュリティ問題の報告者として、影響を受けるコードのメンテナによって修正が受け入れられるまで、“linux-distros” メーリングリストに連絡しないことを強く推奨します。」
`initcall_blacklist`ってやつがあるんだよね。
関連: コピー失敗 https://news.ycombinator.com/item?id=47952181
Ubuntuはパッチを出していて、パッチ適用前後でテスト済みだよ。
参考までに、AF_ALGがカーネルに直接リンクされているカーネルを使っている人のために、eBPFベースの回避策を提供したよ。 https://github.com/Dabbleam/CVE-2026-31431-mitigation 今これを本番環境で動かしていて、攻撃を軽減できてるし、特に予期しない副作用も見当たらないよ。
なんか、AIを使わずに働いてる人を見ると、すごく感慨深い瞬間だなって最近特に思う。
`nosuid` と多分 `nodev` は、個人的にはデフォルトのファイルシステムマウントオプションにすべきだと思う。`/dev` はすでに特別な devtmpfs だし、initrd の最小限の `/dev` は必要に応じて `dev` と `suid` で initrd tmpfs rootfs を明示的にマウントすればいい。SUID バイナリがどこにでも「存在する」ことを許すのは、すごく大きなセキュリティ問題だよ。外部ストレージメディアをマウントした場合、ブロックデバイス上の SUID バイナリが悪意のあるものでないかどうか、どうやって確認するの？さらに、この脆弱性は、SUID バイナリを実行するユーザーがそのバイナリを読み取れる場合にしか機能しないみたい。非ルートユーザーが SUID バイナリを読む必要はないよね。NixOS はこれを正しくやってる。通常のパッケージインストールディレクトリ `/nix/store` には SUID がなくて、その外にパッケージが漏れ出すこともないから、他のマウントポイントでは安全に `nosuid` を使える。例外は、単目的の `/run/wrappers.$hash` ディレクトリだけで、そこには安全に実行可能な SUID ラッパーだけが含まれてる。