Linuxカーネルの脆弱性はディストリビューションに事前通知されない
(openwall.com)- Linuxカーネルのローカル権限昇格脆弱性である CopyFail は、最近のカーネルにおける「make-me-root」脆弱性の中でも 最も深刻な部類 に入る
- 問題は 4.14 の commit
72548b093ee38a6d4f2a19e6ef1948ae05c181f7で導入され、6.18.22、6.19.12、7.0 で修正された - 6.19.12 と 6.18.22 には 4月11日に 修正のバックポート が含まれたが、Longterm 6.12、6.6、6.1、5.15、5.10 には当時修正が入らなかった
- 修正は古いカーネルに clean apply できず、即時配布が必要な状況では IPSec の
authencesnモジュール無効化パッチ を暫定対応として使える - Linuxカーネルの脆弱性は、報告者が linux-distros ML に持ち込まない限りディストリビューションへ事前通知されず、今回も heads-up は行われなかった
CVE-2026-31431 の影響範囲と修正状況
- CopyFail は Linuxカーネルのローカル権限昇格脆弱性であり、最近のカーネルにおける「make-me-root」脆弱性の中でも最も深刻な部類に入る
- 問題は 4.14 の commit
72548b093ee38a6d4f2a19e6ef1948ae05c181f7で導入され、6.18.22、6.19.12、7.0 でそれぞれ修正された - 6.18.22 修正 commit
- 6.19.12 修正 commit
- 7.0 修正 commit
- 6.19.12 と 6.18.22 は 4月11日に 修正バックポート を含んだ状態でリリースされた
- Longterm 6.12、6.6、6.1、5.15、5.10 には当時修正が入っておらず、upstream stable queue にも見当たらなかった
- 2017年に導入された問題であれば、古いカーネルも影響を受けるか確認が必要
ディストリビューションへの事前通知と暫定対応
- 該当修正は古いカーネルに clean apply されない
- 即時配布が必要な状況でバックポートも試みられたが、いくつかの API変更 のため確信を持って進めるのが難しかった
- 暫定対応として IPSec の
authencesnモジュールを無効化するパッチを利用でき、IPSec の専門家でなくても「よりましな選択」に近い - 0001-crypto-disable-authencesn-module-for-CVE-2026-31431.patch: CVE-2026-31431 対応の
authencesnモジュール無効化パッチ - Linuxカーネルの脆弱性は、報告者が linux-distros ML に持ち込まない限りディストリビューションへ事前通知されない
- 今回は linux-distros ML を通じた heads-up は行われなかった
1件のコメント
Hacker Newsの意見
リンク先の記事の執筆者である Sam James は Gentoo 開発者
ともかく、これはほとんど災害に近く、ディストリビューションが修正版を配布する前に exploit を公開したのは非常に無責任だった
これでどれだけ多くの shared hosting 事業者が侵害されたのか分からない
また、kernel security team とディストリビューションの maintainer の間に意思疎通がないように見える点も懸念される
前者が後者に知らせるだろうと期待してしまうが、実際には脆弱性を見つけた人が責任を負う構造のように見える
参考までに、Google Project Zero も同様に「90+30」ポリシーを使っている: https://projectzero.google/vulnerability-disclosure-policy.h...
本当の問題は kernel security team とディストリビューションの maintainer の間にコミュニケーションチャネルがないことだ
脆弱性を発見した人がすべての downstream に個別報告する責任を負うべきではない
kernel チームがディストリビューションのセキュリティ担当者リストに、パッチの重要度と30日後に公開する予定を知らせるべきだった
公開ページにも「Is your software AI-era safe?」、「Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem」、「[Try Xint Code]」のような文句がある
混乱が大きくなるほど製品がより魅力的に見えるようにするやり方だ
Responsible Disclosure という表現は「Secure Boot」のように言語的によく設計された言い回しで、実際には私のコンピュータと私の間にいる企業・財団といった中間組織の評判管理のためのものに見える
彼らは私個人のコンピュータが脆弱かどうかより、「RHEL が脆弱だ」「Ubuntu が脆弱だ」と言われないことに関心がある
脆弱性はどうせ存在するのだから、静かに修正されるのを待つより、リスクを知って減らす機会があるほうがよいと思う
つまり、即時公開だけが無責任ではない選択だと思う
互いに信頼しない tenant workload を 単一の shared kernel の下で動かすのは妥当ではない
Kernel LPE は珍しいものではなく、今回は特に単純で移植性が高かっただけで、根本的な capability 自体は CNE commodity に近い
shared hosting をしながら侵害を避けたいなら、gVisor や Firecracker VM のような別の手段を使うべきだ
これをセキュリティ境界として使う重要なシステムは Android くらいだが、APK インストール時のユーザー承認、厳格な SELinux と seccomp ポリシー、GrapheneOS hardening があるため緩和されている
今回も緩和は成功していた: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...
「Linux kernel 脆弱性の場合、reporter が linux-distros ML に直接持ち込まない限りディストリビューションには事前通知がない」といった言い方をする理由が分からない
reporter がディストリビューションと直接調整しなければならないというのは、Linux プロジェクトについて高度な知識を前提としている
脆弱性の報告者が Linux kernel のすべての downstream 利用者と直接やり取りする責任を負うべきではない
そう言うなら、Linux を機器に使うすべてのメーカーにも直接連絡すべきなのかという話になる
報告者は Linux に責任ある形で公開し、パッチが入るまで待っただけでも十分にやったと思う
Linux プロジェクト内部に、セキュリティ脆弱性について権限と責任を持つ人たちがいるべきで、downstream distro への通知も彼らが担うべきだと思う
https://docs.kernel.org/process/security-bugs.html
As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.少なくともそれらのディストリビューションのセキュリティチームには知らせるのが責任ある行動だったはずだ
それらのディストリビューションが kernel チームの downstream であることを知らなかったはずもない
Google 検索だけでも出てくる: https://share.google/aimode/eihDKXZJy94Z5lC1p
これを考えもせず全員を exploit にさらすのは理解しがたく、一部の法域では重罪でもおかしくないと思う
disclosure に関連して最も興味深いやり取りはこのリンクにある
https://www.openwall.com/lists/oss-security/2026/05/01/3
「私たちは誰にも事前通知できない。そうすると、すべてについて全員に知らせなければならなくなるからだ。法執行機関や政府機関が私たちの運営を認めた唯一の方針がそれなので、どうしようもない」という greg k-h の返答だ
reporter を責めるのをやめて、kernel プロセス を直せと求めるべきだ
Linux kernel はもはやおもちゃのプロジェクトではなく、複数の企業に雇われたフルタイムの従業員がいる
ディストリビューションへの通知は任意の個人ではなく、彼らが処理すべきだった
RHEL 14 のような言及をそう入れていなければ、ここまで非難されなかった気がする
これは個人のセキュリティ研究者や学術界ではなく、専門のコミュニケーション部門を持つセキュリティ企業が distro maintainer に向けて責任転嫁している状況だ
しかし、reporter がそれを待たなかったために実際に被害を受けた人がいるかもしれず、その責任は reporter にある
主要ディストリビューションに先に知らせず世に放ったのは無責任だった
AF_ALG がモジュールではなく kernel に直接リンクされた kernel を使っている人向けに、eBPF ベースの workaround が公開されている: https://github.com/Dabbleam/CVE-2026-31431-mitigation
現在 production で動かしており、攻撃を緩和していて、今のところ予期しない副作用は見えていない
nosuidと、おそらくnodevはデフォルトの filesystem mount option であるべきだと思う/devはすでに特別な devtmpfs であり、initrd の最小限の/devが必要なら、initrd tmpfs rootfs をdevとsuidで明示的に mount すればよいSUID binary がどこにでも「存在」できるままにしておくのは大きなセキュリティリスクだ
外部ストレージを mount したとき、その block device 内の SUID binary が悪意あるものではないとどう検証するのか
しかもこの exploit は、SUID binary を実行するユーザーがその binary を読める必要もあるように見える
non-root ユーザーが SUID binary に read 権限を持つ理由はない
NixOS はこれを正しく扱っている
一般的なパッケージインストールディレクトリである
/nix/storeには SUID がなく、パッケージがそこから漏れ出さないので、他の mountpoint には安全にnosuidを使える例外は、executable-only の SUID wrapper だけを安全に収める単一目的の
/run/wrappers.$hashディレクトリだけだexploit されるバグは事実上、任意の page cache poisoning を可能にする
その時点でもう勝負は決しており、suid プログラムへのパッチは root shell を得る最も簡単な方法ではあっても、唯一の方法ではない
他の方法はいくらでもある
概念実証 exploit だけを防ぐのが目的なら、blacklist のようなもっと簡単な方法もあるが、それでより安全になるわけではない
この脆弱性では page cache を操作できる
ld.soを改変して任意の system call に hook をかけたり、uid を 0 に書き換えたり、その他さまざまな方法で権限昇格が可能だmount point はこの問題と関係がない
もちろん、ユーザー書き込み可能な領域で suid を防ぎ、suid ファイルの読み取りを防ぐのは常によい考えだが、それは別の理由による
NixOS でもこの脆弱性は防げず、他のディストリビューションと同様に脆弱だ
binary を実行するには、ディスクから読んでメモリにロードしなければならない
実際、特定の binary に read 権限はあるが executable 権限がない場合でも、linker を直接呼んで実行できる
たとえば
/bin/ld.so.1 /path/to/binaryのように呼び出せば、linker が binary を読み込んでロードし、exec()を呼ばずに entry point にジャンプする以下の Bleeping Computer のリンクには、パッチの準備ができるまでの潜在的な対策が載っている
https://www.bleepingcomputer.com/news/security/new-linux-cop...
RHEL、Fedora、Gentoo はいずれもこのコードを kernel に直接ビルドする設定になっている
パッチや設定変更がなければ、Sam が Gentoo で示唆したように、それらのディストリビューションは引き続き脆弱だ
NixOS も通知を受けていなかった
https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...
Hyperbola GNU は、政治的理由と安定性のためにまだ Python 3.8 を使っていたので安全だった
Ubuntu はパッチを出しており、パッチ前後でのテストも完了している