はじめに
お盆が明けました。大人の夏休みも終わり、そろそろ仕事の顔に戻る時期です。
今日並べる5本には、地味に共通点があります。どれも「コードは昔のまま」なのです。2008年から潜んでいたKVMのバグ、30年動き続けてきたrsync、CPUが5年前から積んでいたのに使われてこなかった保護機能、設計当初から変わっていないjournaldの書き込み方式。新しく壊れたものは、実はほとんどありません。
変わったのは、掘る道具と動かす環境のほうです。AIレビューツールとファジングと集中監査が、人間が見落としてきた場所を掘り返し、ネスト仮想化やlarge folioやCopy-on-Writeといった「昔はなかった環境」が、眠っていた設計の粗をきっちり増幅して表に出しました。今日はその答え合わせの日です。
1. 借りた仮想マシンから、ホストの管理室へ — CVE-2026-64561「Zapscape」
まずは重いところから。クラウドで借りたVMの中から、その下のホストOSにroot権限で抜け出せてしまう脆弱性です。NVD がCVSS v3.1で8.8（HIGH）、ベクターは AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H と評価しています。スコープが S:C、つまり「影響が自分の境界を越えて広がる」と明示されているところに、この脆弱性の性格が出ています。
問題があるのはLinux KVMのx86シャドウMMU、ゲストの物理アドレスとホストの物理アドレスを対応づけるページテーブルの管理部分です。メモリが足りなくなるとKVMはシャドウページを解放（zap）して再利用するのですが、ページフォルト処理の2経路で「解放を実行する」のと「いま使っているルートが無効化されていないか確認する」の順序が逆になっていました。確認を先に済ませてから解放が走るので、その解放でルート自体が無効になっても誰も気づかない。結果として、解放済みのルートの下にマッピングを積み上げ続け、use-after-freeに至ります。
面白いのは修正の小ささです。修正コミット 2abd5287f083（2026年7月21日マージ）がやっているのは、チェックを解放処理の後ろに移して、無効化されていたら RET_PF_RETRY を返して再試行させるだけ。十数行です。クラウド全体を揺らす話の解決策が、順序の入れ替えだったわけです。
そして、このバグ自体は2008年当時のコードからずっとそこにありました。2020年のLinux 5.9で「無効化されたシャドウページはアクティブページリストに載ってはならない」という不変条件が明文化されたことで、既存の順序バグが実際に踏める地雷として顕在化した、という経緯です。発見者のHyunwoo Kim氏による公開開示は oss-security メーリングリスト に8月6日付で投稿されています。
条件は押さえておきましょう。「KVMを使っていれば全部危ない」という話ではありません。前提としてホスト側でネスト仮想化（ゲストの中でさらに仮想化を動かす機能）が有効である必要があり、Intel環境ではさらにEPTページウォーク長4と5の両方がL1ゲストに露出している構成に限られます。一方AMD環境では追加条件なしで成立するとされていて、EPYCが増えている今のクラウド市場を考えると、実際のリスクの広がりはスコアの数字以上かもしれません。
影響はLinux 5.9以降、修正済みは6.6.148 / 6.12.101 / 6.18.42 / 7.1.6 / 7.2-rc5 以降です。なお Red Hat は自社評価でCVSS 7.0（Important）としており、NVDの8.8とは差があります。ゲスト内root前提という条件をどう見積もるかの違いで、どちらが正しいというより、評価する立場の違いが出た形です。対応はディストリのカーネル更新とホスト再起動が最優先、すぐ再起動できないならネスト仮想化を一時的に切る、/dev/kvm へのアクセスを絞る、あたりが現実的な緩和策になります。
2. Linux 7.2 は「まだ」出ていない — AIレビューが変えた開発サイクル
続いてカーネル本体の話。……なのですが、まず訂正から入らせてください。この記事を書いている2026年8月17日時点で、Linux 7.2の安定版はまだ出ていません。kernel.org の releases.json を確認したところ、mainlineは 7.2-rc7（2026年8月9日）、latest_stableは 7.1.8 のままでした。
Phoronix によればrc7の時点でLinus Torvalds氏は「次の日曜（8月16日）に安定版」を見込んでいたので、1日ほど後ろにずれている計算になります。この手のスケジュールは普通に前後するので、いま慌ててニュースを探しても仕方ありません。数日中には出るでしょう。
それより印象的なのは、今サイクルのRCの太り方です。rc6はコミット数でここ数年最大のrc6として記録され、rc7も例年より大きくなりました。理由がはっきりしていて、AI・LLMベースのコードレビューツールが大量のパッチを生み出しているためです。Torvalds氏本人がrc7のアナウンスでこう書いています。
I can’t say that I’m exactly thrilled about the size of this all, but it is what it is: the new normal with a lot of fixes, many of them due to review by various AI tools.
「手放しで喜べるわけではないが、これが新しい常態だ」という言い回しに、諦めというより現実の受け入れが滲んでいて、個人的にはここが一番好きでした。カーネルの方針自体は変わっておらず、AIが見つけた修正であっても人間がトリアージしてサインオフしなければマージされません。道具が増えただけで、門番はそのままです。
象徴的だったのが、2018年のLinux 4.16時代から8年間検出を逃れていたptdumpの競合状態が見つかった件で、BetaNews によればClaude Opus 4.8が発見に貢献したと報じられています。8年間、人間のレビュアーが誰も気づかなかったものが掘り起こされた。これも「コードは昔のまま、掘る道具が変わった」の一例です。
機能面では、Cache Aware Scheduling が今回の目玉です。EPYCやXeonのようなマルチチップレットCPUは、ラストレベルキャッシュ（LLC）のドメインを複数持ちます。データを共有し合うタスクが別々のLLCドメインに散ると、そのたびにドメイン間でデータが往復してレイテンシが悪化する。この「キャッシュ・バウンシング」を避けるために、スケジューラがタスクの共有パターンを見て同じLLCドメインへまとめる仕組みで、CONFIG_SCHED_CACHE で有効・無効を選べます。PostgreSQLやValkeyといったワークロードで効果が報告されています。ほかにAMD Zen 6（EPYC 9006「Venice」）のサポート、AMDGPUのHDMI 2.1 FRL初期対応（認証手続き中のためデフォルト無効）、MGLRUの改善によるMongoDB系ワークロードのスループット改善、そして6年・360本超のパッチをかけた strncpy() のカーネルからの完全除去が入っています。最後のやつ、地味ですが6年です。
3. 5年待った盾 — Fedora 45がShadow Stackをデフォルト有効化
軽めの話題を挟みます。Fedora Linux 45 が、x86_64のShadow Stack保護をシステム全体でデフォルト有効化する変更提案を採択しました。Red HatのArjun Shankar氏が変更責任者で、FESCoチケット #3636 で承認されています。
Shadow StackはIntel CET（Control Flow Enforcement Technology）の一部で、ROP（Return-Oriented Programming）攻撃をCPUレベルで止める仕組みです。ROPは既存コードの断片を ret 命令で数珠つなぎにして任意のコードを実行する手法で、バッファオーバーフローが潰されてきた今でも有効な攻撃手段として残っています。Shadow Stackはリターンアドレスのコピーを、通常のコードからは触れない専用領域に二重に持っておき、ret のたびにCPUが両者を突き合わせます。食い違えばそこでプロセスを止める。判定するのがソフトウェアではなくCPUのパイプラインなので、迂回する余地がほとんどありません。
有効化を担うのはglibcの動的リンカです。ELFバイナリの .note.gnu.property に GNU_PROPERTY_X86_FEATURE_1_SHSTK というフラグが埋まっていて、実行ファイルと依存ライブラリの全部がこれを持っているときだけ保護が有効になります。一つでも非対応があれば、その実行では有効化されません。Fedoraは2018年から -fcf-protection=full をデフォルトでビルドに適用してきたので、リポジトリ内のパッケージは大半がすでに対応済みという下地があります。Rustについても、Bugzilla #2196282 で追跡されていた問題が rust-1.97.1-2.fc45 で解決済みです。
対象CPUはIntel第11世代以降とAMD Zen 3以降。どちらも2020年の製品です。ハードウェアが5年以上前から積んでいた盾を、OS側がようやくデフォルトで構えた、という話になります。仕様も実装もずっと前からあったのに、コンパイラ・libc・カーネル・パッケージ群の足並みが揃うまでにこれだけかかった。エコシステム全体を動かすことの難しさが、そのまま時間になって出ています。
引っかかりそうなのはFirefoxとChromeです。どちらもJITコンパイラが生成するコードがShadow Stackの制約と衝突するため、上流での対応が済むまではビルド時に保護フラグを外す方針とされています。毎日使うアプリが当面は保護対象外というのは、正直ちょっと据わりが悪いところです。性能への影響については、CPUが強制する仕組みでソフトウェア側の計装が不要なため「典型的なワークロードでは計測可能な影響はない」とされています。もし個別のアプリで互換性問題が出た場合は、/etc/tunables.conf.d/ 配下に設定ファイルを置いてそのアプリだけ無効化できます。動的ロードされたライブラリが非対応だと dlopen: rebuild shared object with SHSTK support enabled というエラーになるので、プラグインが急に読めなくなったらこれを疑ってください。
4. ログ1行で55KB — systemd-journaldの書き込み増幅
さて、今日いちばん「自分の環境は大丈夫か」と気になる話です。systemd-journaldは、ログを1行書くだけで、実際のブロックデバイスへの書き込みがそれとは桁違いの量になっている、という報告です。
一次情報は systemd の issue #40262 です。2026年1月3日に「Excessive IO caused by systemd-journald」として起票されたもので（2020年にも同種の報告があり、再現性なしとしてクローズされていました）、8月3日に研究者のValdikSS氏が精密な実測を投稿したことで一気に注目されました。tmpfs上にext4のループデバイスを作り、そこだけを /var/log/journal にマウントして、logger -p info test 1行あたりのブロックデバイス書き込みを測るという手堅い方法です。
結果は、氏の言葉をそのまま借りれば「1件のログメッセージでも、同種のメッセージ10件でも、少なくとも55KBの書き込みが発生する」というものでした。14件のログで物理書き込みは386KB。比較として、通常のappend + fdatasync + fsyncであれば3件で約21KBに収まります。btrfsではさらに増え、Copy-on-Writeの性質上どうしても新規割り当てとメタデータ更新が連鎖するため、1行あたり100KBを超える増分が記録されています。
原因は2つ重なっています。1つはjournaldが mmap() による共有ファイルマッピングでジャーナルに書いていること。もう1つは、カーネルのlarge folio（ページキャッシュの最適化）です。従来はmmap領域の1バイトを書き換えると4KBの1ページだけがdirtyになりましたが、large folio以降はfolio全体（典型的には16KB〜64KB）がまとめてdirtyとしてマークされ、書いた実データをはるかに超える量が一度に書き出されます。
ここで多くの人が誤解しているのが SyncIntervalSec です。デフォルト5分のこの設定を見て「5分に1回しかディスクに書かない」と思い込みがちですが、そうではありません。ValdikSS氏も測定の途中で気づいて驚いていて、これはfdatasync/fsyncを発行する間隔であって、データ書き込み自体の間隔ではないのです。mmapに書いた時点でカーネルのwritebackが判断したタイミングで実I/Oが飛びます。設定名がミスリーディングだという批判はもっともだと思います。
反応も濃いものでした。bcachefs開発者のKent Overstreet氏は、Reddit（r/bcachefs）で「large folio以降、mmap書き込みはどのファイルシステムでも壊れている、クラウドプロバイダはこの理由でfolioを使っていない」という趣旨の発言をしており、それが8月14日に別のユーザーによってissueへ転記されて話題になりました。GitHubアカウントからMatthew Wilcox氏とみられるiomapのメンテナは、folio全体ではなく該当ページだけをdirtyにするパッチをissueに投稿していますが、本人が「起動は確認したが、fstests一式はまだ通していない」と書いているとおり、まだ検証途中の段階です。同じくAndy Lutomirski氏とみられるx86カーネル開発者は、自分もかつてmmap書き込みでデータベースを作ったが設計として誤りだった、pwriteを使うべきだった、と述べています。
ただし、どこまで広く再現するのかはまだ確定していません。カーネルのバージョンや設定への依存がどの程度あるかは調査中で、「すべてのディストリビューションで再現する」と言い切れる出典はまだない状態です。原因の帰属自体も仮説の域を出ていません。それでも、SSDのTBW（書き込み耐久値）が気になる環境や、IOPSに料金がかかるクラウド環境では、無視できない話です。すぐ効く緩和策としては Storage=volatile でジャーナルをメモリのみにする（再起動でログは消えます）、rsyslogやsyslog-ngへ転送してjournald側は揮発にする、といったあたりが挙がっています。
5. 30年目のrsync、33件のCVEを一括修正
最後も重い話です。2026年8月13日にリリースされた rsync 3.5.0 は、33件のセキュリティ問題を一度に修正しました。公式 NEWS は “This has been an extraordinary release developed over several months.” と書いていて、開発チーム自身が異例のリリースだと認めています。
筆頭は CVE-2026-53791、CVSS 9.1のCriticalです。rsyncデーモンで proxy protocol = true を設定している場合、信頼できるプロキシを経由せず直接つないできたクライアントが自前の PROXY ヘッダを送るだけで送信元IPアドレスを詐称できました。hosts allow / hosts deny によるIPベースのアクセス制御が丸ごと素通りになるわけで、Criticalも納得です。3.5.0では、転送されたアドレスを信頼するのは設定済みの信頼プロキシからのものだけになりました。設定オプションの名前は proxy protocol hosts で、proxy protocol = true にしたままこれを設定していないと全接続が拒否されるという動作変更が入っています。アップグレード後に設定を確認しておかないと、ある日突然つながらなくなって慌てることになりそうです。
件数として多いのはシンボリックリンク競合の一群、約15件です。パス解決のTOCTOU（確認した時点と使う時点のあいだに状態が変わる競合）を突いて、フィルタマージファイルや認証ファイルの読み出し、ログファイルやバッチファイルのパスを経由した任意ファイルへの書き込み（~/.ssh/authorized_keys への追記など）、デーモンモジュールのルート外へのアクセスといったことが可能になっていました。
修正の考え方が良いです。個別に穴を塞ぐのではなく、secure_relative_open() という新しい関数を導入して、パスの解決方法そのものを差し替えました。NEWSによれば、Linux 5.6以降・FreeBSD 13以降・macOS 15以降ではカーネルが強制する「dirfdより下から出ない」パス解決を使い、シンボリックリンクによる脱出を防ぎます。ツリー内のシンボリックリンクは引き続き追跡できるので、機能を殺さずに逸脱だけを止める形です。穴を塞いだのではなく、穴を開けられない材料に替えた、という表現がしっくりきます。
ほかにファジングで見つかったヒープの範囲外書き込みも複数あります。CVE-2026-70456（CVSS 8.8）は read_args() で引数リストが割り当てサイズちょうどになったときに終端のNULLを1つ先へ書いてしまうもので、影響範囲は3.0.1から3.4.4と広めです。CVE-2026-70461（CVSS 8.8）はパス末尾のバックスラッシュがバッファサイズの計算から漏れて1バイトはみ出すというもの。33件すべてに回帰テストが付いていて、修正前のコードで落ちることが確認されているのは、地味ですが誠実な仕事だと思います。
影響範囲の見積もりは冷静にいきましょう。rsyncはどこにでもあるツールですが、今回の33件はパス処理とデーモンプロトコルの監査で出てきたものです。主に効いてくるのは、rsyncデーモンをインターネットに公開している環境、特権プロセスでrsyncを走らせている環境、CI/CDや自動バックアップで攻撃者がシンボリックリンクを仕込みうる経路がある環境です。手元から単発で rsync -av を叩くだけの使い方であれば、影響は限定的とみられます。とはいえアップグレード自体は難しくないので、3.5.0が降ってきたら素直に上げておくのが早いはずです。
まとめ
5本を並べてみると、今日の話はどれも「新しく壊れた」話ではありませんでした。KVMのバグは2008年からそこにあり、rsyncのパス処理は30年動き続け、Shadow Stackは5年前からCPUに載っていて、journaldのmmap書き込みは設計当初のままです。
変わったのは掘る道具のほうです。AIレビューツールがカーネルのRCを膨らませ、8年間見つからなかった競合を掘り出した。ファジングと集中監査がrsyncから33件を一度に引き出した。そして動かす環境も変わりました。ネスト仮想化が当たり前になったからKVMのバグは踏める地雷になり、large folioが入ったからログ1行が55KBになった。コードは何も悪くなっていないのに、周りが変わったせいで表に出てきたわけです。
となると気になるのは、自分の環境で「まだ掘られていないだけ」のものがどれくらいあるのか、ですね。今日のうちに確認しておくなら、順番としてはKVMホストのカーネル更新、rsyncデーモンの公開状況、そして iotop -a あたりでjournaldの書き込み量を眺めてみる、といったところでしょうか。皆さんの環境は、今日どれに当たりましたか。