- Hacker Newsの見出しによれば、過去24時間で LinuxカーネルのCVE 432件 が公開されたが、現在の告知ページでは個別の内容を確認できない
- 告知ページは、大規模なWeb収集による サーバー停止とリソースアクセス制限 を防ぐため、Anubisのボット対策手順を適用している
- Hashcash系のプルーフ・オブ・ワーク（Proof-of-Work） により、通常アクセスの負担は小さく保ちながら、大量収集の累積コストを高めている
- この方式は、ヘッドレスブラウザを識別する技術が整うまで使う 暫定的な解決策 である
- 最新のJavaScript機能が必要で、JShelterのようにこれを遮断するプラグインは、そのドメインで無効化しなければアクセスできない
CVE告知ページの現在の状態
- Hacker Newsの見出しでは、過去24時間で LinuxカーネルのCVE 432件 が公開されたとしているが、提示されたページにはCVE一覧や詳細内容がない
- 代わりに難易度4の プルーフ・オブ・ワーク計算画面 だけが表示される
Anubisの動作方式と制約
- Hashcash系のプルーフ・オブ・ワーク は、個々のアクセスには無視できる程度の計算負荷を与える一方、大規模収集には累積コストを発生させる
- 今後はフォントレンダリング方式などによって ヘッドレスブラウザをフィンガープリント識別 し、通常ユーザーにはプルーフ・オブ・ワークページを表示しない方式を目指している
- Anubisが要求する最新のJavaScript機能をJShelterなどが遮断する場合があり、そのプラグインを無効化しなければアクセスできない
1件のコメント
Lobste.rs のコメント
CVE は脆弱性そのものではなく識別子であり、実際に脆弱性が見つかったときに付与されるもの
Linux カーネルプロジェクトは、性能修正、ハードウェアのバグ修正、ファイルシステム破損などを除く大半のバグを CVE 候補と見なすと何度も述べている
http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/
CVE の仕組みはもともと製品のために作られたもので、複数の製品の構成要素として使われる OS カーネルとは相性がよくない。理想的には、CachyOS、カーネル内蔵カメラのメーカー、Red Hat が、同じバグについてそれぞれの環境で CVE 候補かどうかを独立して判断すべきである
しかしそうすると、カメラ 300 種、USB 挿入時に特殊な動作をするファイルサーバールーター 300 種、SD カードを使うレトロゲームエミュレーションコンソール数十種に、それぞれ CVE が発生しかねない。そのため、構造的には不自然でも、構成要素の段階で管理するほうがエコシステム全体にはよい
この中に特に興味深い脆弱性があるのか気になる
多くの項目が「Linux カーネルで次の脆弱性が修正されました」という文言で始まっている
我慢できず、LLM に各 CVE へ目を引く名前を付けてもらうよう依頼した
https://git.infradead.org/~rw/cvenames-2026-07-19.html
最初の XFS 関連項目を見ると、細工されたログでのみ問題が発生するとされている
実際の悪用にはファイルシステムをオフラインにし、ログが保存されたブロックデバイスに直接書き込む必要がありそうだ。だとすると root 権限または物理アクセス権限と、システムを停止できる能力が必要に見える。XFS ログを誤解しているのか気になる
例えば、誰かが「写真」が入っていると言って渡してきた SD カードに悪意ある XFS ファイルシステムが入っており、自宅で接続すると脆弱性の連鎖攻撃が実行される可能性がある。ファイルシステムのマウントも、画像ファイルを開くのと同じように安全な操作であるべきだ
ストレージデバイスを接続すると自動マウントするキオスク型デバイスがあるかもしれないし、普段は非現実的に見える問題でも、複数の欠陥や特定の環境が組み合わさると現実的な攻撃になる
カメラに映っていても、同じラックの別サーバーに接続しているのではない、という事実まで鮮明に確認するのは難しい