Linuxカーネルの脆弱性はディストリビューションに事前通知されない
(openwall.com)- Linuxカーネルのローカル権限昇格脆弱性 CopyFail は、近年のカーネルにおける「make-me-root」（一般ユーザーをrootにしてしまう）脆弱性の中でも 最も深刻な部類 に入る
- この脆弱性はカーネルバージョン 4.14 の特定コミットで導入されており、CopyFailで悪用された
authencesnモジュールに インプレース最適化が追加された時点 と一致する - 修正はカーネル 6.18.22、6.19.12、7.0 に反映されており、6.18.22と6.19.12は4月11日に修正がバックポートされた状態でリリースされた
- しかし、依然として広く使われている Longtermカーネル（6.12、6.6、6.1、5.15、5.10）にはこの修正が含まれておらず、upstream stable queueでも確認されていない状態
- 2017年に導入された問題であるため、これらの古いLongtermカーネルも影響を受けるか確認が必要な状況
- 該当する修正パッチは古いカーネルには clean apply（コード衝突なしにきれいに適用）できず、いくつかの API変更 のため、バックポートを試みるにしても確信を持って進めにくい状況
- 即時対応が必要な環境では、暫定措置としてIPSecの
authencesnモジュールを無効化するパッチ を適用でき、IPSecの専門家でなくても「完璧ではないが、よりましな選択」に当たる - つまり、構造的な問題 はLinuxカーネル脆弱性の公開プロセスそのものにある:
- Linuxカーネル脆弱性は、脆弱性報告者が自ら linux-distrosメーリングリスト（ディストリビューションのセキュリティチームが集まる非公開チャネル）に通知しない限り、各ディストリビューションへ 事前通知が届かない仕組み
- 今回のCopyFailでも、linux-distros MLを通じた 事前警告（heads-up）は行われなかった
- つまり、Ubuntu・RHEL・SUSEなど主要ディストリビューションのセキュリティチームは、脆弱性公開前にパッチを準備する機会を持てなかった
2件のコメント
ブログ記事は少し幼稚ではあるものの、不快だという以上の誤りを評価するには、システム的な欠陥のほうがより大きいように思います。
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 はパッチを出しており、パッチ前後でのテストも完了している