Linux

Linux 7.2-rc1公開。6年越しの安全対策が完了

情報の灯台

2026年6月29日 22:0400

Linux 7.2のマージウィンドウが閉じ、最初のリリース候補が現地時間6月28日に公開された。パッチの3分の1をAMD GPUのレジスタ定義が占めているが、その裏では6年がかりのセキュリティ改善が完結し、AMDのHDMI 2.1対応やUSB4の新プロトコルなど、実用に響く変更が揃った。安定版は8月下旬の見込みで、カーネルのソースコードは総行数4389万行を超えた。

6年362コミット、`strncpy()`が消えた

Linux 7.2で最も意味のある変更は、新機能の追加ではなく削除だ。

C言語の文字列コピー関数strncpy()が、カーネルのソースツリーから完全に除去された。6月20日のマージで、関数の実装そのものと全アーキテクチャ固有の最適化コードが一括で消えている。

strncpy()の問題は、コピー先バッファの末尾にヌル終端文字を保証しない設計にある。コピー元の文字列がバッファサイズに達すると、終端なしのバッファがカーネル内に残る。後続のコードがこのバッファを通常の文字列として読むと、バッファ境界を越えてカーネルメモリの隣接領域まで読み進めてしまう。認証情報や暗号鍵が漏洩するリスクを、関数の仕様自体が抱えていた。カーネル自身のドキュメントがstrncpy()を「持続的なバグの発生源」と記載していたほどだ。

この関数をカーネルから消す作業を主導したのは、Googleのキース・クック（Kees Cook）氏。Kernel Self Protection Project（カーネル自己防衛プロジェクト）を率いるセキュリティエンジニアで、2024年1月にstrlcpy()の除去を完了した直後、strncpy()を次の標的に定めた。

ただし単純な置換はできない。カーネル内の呼び出し箇所ごとに、文字列コピーの意図が異なっていた。ヌル終端が必要な通常のコピー、ゼロパディングが目的のコピー、ヌル終端を前提としない固定幅バイナリフィールドへの書き込み。1つの関数名の下に5種類の異なる操作が混在していたため、全呼び出し箇所を個別に読み解き、意図に合った代替関数に書き換える必要があった。

6年間で362コミット、70人の開発者が参加した。最多は211コミットを担当したジャスティン・スティット（Justin Stitt）氏。最後の6箇所をクック氏自身が処理し、実装を削除した。

この除去が単なる整理と違うのは、効果が恒久的だからだ。strncpy()の実装がソースツリーに存在しなくなったため、今後どの開発者が新しいコードでこの関数を使おうとしても、コンパイルの時点で失敗する。非推奨のラベルを貼って注意を促す段階から、使用そのものが不可能な段階へ移行した。コードレビューで見落とす余地がなくなったことが、362コミット分の値打ちだ。

HDMI 2.1が、ようやくAMDのオープンソースドライバに来た

AMDGPUドライバにHDMI 2.1 FRL（Fixed Rate Link）の初期サポートがマージされた。

Radeon GPUのオープンソースドライバは、長年HDMI 2.0世代の信号方式（TMDS）に制限されていた。4K 120Hzや8K 60Hzといった高解像度・高リフレッシュレートの出力にはFRLが必須だが、HDMI Forumのライセンス方針がオープンソース実装を阻んできた経緯がある。AMDは2023年から法務チームとともにオープンソースで公開可能な実装を模索したが、2024年2月にHDMI Forumに却下されている。

2026年5月、AMDのハリー・ウェントランド（Harry Wentland）氏がFRLパッチシリーズをカーネルメーリングリストに投稿。HDMI準拠テストの代表的なサブセットに合格した状態での提出で、Linux 7.2のDRMマージに含まれた。

ただし、現時点のFRLサポートはデフォルト無効だ。有効化にはカーネルパラメータの手動設定が必要で、VRR（可変リフレッシュレート）やDSC（Display Stream Compression）はまだ実装されていない。完全なHDMI 2.1対応は段階的に進む。

それでも、AMDがオープンソースでHDMI 2.1のコードを公開できた事実に意味がある。HDMI ForumがLinuxでのオープンソース実装を事実上認めた形であり、Steam MachineをはじめとするLinux搭載ハードウェアにとって、HDMI出力の制約が解消に向かう転換点だ。

AMD GPU所有者がLinuxのオープンソースドライバでHDMI接続の4K 120Hz出力を得られるのは、RX 6000シリーズの発売以来初めてだ。

USB4ケーブル1本で、ネットワーク不要のデータ転送

Intelのミカ・ヴェステルベリ（Mika Westerberg）氏らが開発したUSB4STREAMプロトコルがLinux 7.2にマージされた。USB4またはThunderboltケーブルで直結した2台のマシン間で、ネットワークスタックを経由せずに生データを転送する仕組みだ。

各ホストに/dev/tbstreamXというキャラクタデバイスが生成され、通常のファイル操作（read()/write()）でデータを送受信する。Unixの「すべてはファイル」という設計思想がそのまま活きるため、ddやtar、GStreamerなど既存のツールで扱える。アプリケーション側の変更は不要だ。

想定される用途は、リカバリ環境でのディスクバックアップ、ファイルシステムの転送、ウェブカメラの共有など。特にinitramfs環境でSSHもネットワーク設定も不要になる点は、障害復旧の手順を大幅に簡素化する。

現時点ではConfigFSインターフェースによる手動セットアップが必要だが、手順は定型化されており、自動化も可能だとヴェステルベリ氏はドキュメントで示している。

スケジューラがL3キャッシュを認識する

Linux 7.2にキャッシュアウェアスケジューリング（CAS）がマージされた。Intel主導で1年以上の開発期間を経た機能で、CONFIG_SCHED_CACHEで有効化する。

従来のスケジューラはNUMAノードやコアの論理構成は理解していたが、LLC（Last Level Cache、最終レベルキャッシュ）の物理的な境界を積極的には考慮していなかった。コアが1つのダイに収まり、L3キャッシュを全コアで共有していた時代には問題にならなかったが、AMD EPYCのCCD構成やIntel Xeon 6のパーティション構成のように、1ソケット内に複数の独立したL3キャッシュ領域を持つ現代のサーバCPUでは、データを共有するタスクが異なるLLCドメインに配置されると、キャッシュミスとメモリレイテンシが増大する。

CASはタスク配置時にLLC境界を認識し、データを共有するタスクを同一LLCドメインに集約する。全体の負荷分散は維持したまま、キャッシュの局所性を高める設計だ。

Phoronixの初期ベンチマークでは、AMD EPYC 8635P（84コア/168スレッド、Zen 5）でローカルホストのネットワーク性能が改善し、消費電力はLinux 7.1比で微減という結果が報じられている。データベースやネットワーキング、高並行性ワークロードで恩恵が大きいとみられる。

パッチの3分の1はAMDのレジスタ定義

トーバルズ氏は7.2-rc1のアナウンスで、パッチ全体の統計は通常通りだと述べた。ただし、AMDGPUのレジスタヘッダの一括更新がパッチの約3分の1を占めており、見かけのサイズを押し上げている。この部分を除けば、パッチの半分強がドライバ（GPU以外のドライバも含む）、残りがアーキテクチャ更新、ツール、ドキュメント、コアカーネルの更新と、ここ数リリースと同じ構成比になる。

Linux 7.2 ソースコード構成（cloc集計）

区分	行数	割合
コード	3365万行	76.6%
空白	521万行	11.9%
コメント	503万行	11.5%
合計	4389万行	100%

※cloc（Count Lines of Code）による2026年6月28日時点の計測。ファイル数10万8158

Linux 7.2のソースツリーは、cloc集計でファイル数10万8158、空白行521万行、コメント行503万行、コード行3365万行、合計4389万8743行に達した。Linux 7.1の4292万行から約97万4000行の純増だ。i486サブアーキテクチャの残りや旧ドライバの除去があっても、新機能の流入が大幅に上回った。

AMDGPUスタック単体で約635万行に膨らんでおり、カーネル内の単一ドライバとしては最大だ。