カーネルライブパッチ本番適用｜月次パッチを再起動ゼロで吸収する段階展開とロールバック設計

カーネルライブパッチとは何か、月次CVEになぜ有効か

カーネルライブパッチ（Kernel Live Patching）は、稼働中のLinuxカーネルに対してメモリ上でパッチを適用する技術です。通常のカーネルアップデートではシステムの再起動が必須ですが、ライブパッチは関数単位でカーネルコードをホットリプレースするため、サービスを停止せずに脆弱性を修正できます。

月次CVE対応の文脈でこの技術が注目される理由は、「修正を適用したいタイミング」と「再起動ウィンドウを確保できるタイミング」のギャップにあります。NVDが公開する月次のカーネル関連CVEには、リモートコード実行（RCE）や権限昇格（LPE）を引き起こすCVSS 7.0以上のものが定期的に含まれます。深刻度の高い脆弱性は公開後数日以内に攻撃コードが出回るケースもあり、「次のメンテナンスウィンドウまで待つ」という判断にはリスクが伴います。ライブパッチを活用すれば、再起動スケジュールを調整する前に脆弱性を封じ込めることができます。

ただし、ライブパッチはあくまで「一時的な封じ込め措置」という位置づけです。適用済みのライブパッチはカーネルバージョンに紐付いているため、次回の正規カーネルアップデート（再起動を伴う）を実施するまでの橋渡し手段として設計するのが正しい運用です。ライブパッチを導入しても、メンテナンスウィンドウでの再起動アップデート計画は引き続き必要になります。

主要ディストリビューションの対応状況（2026年現行）

ライブパッチの実装はディストリビューションごとに異なります。本番環境での採用前に、自社の環境がどのサービスに対応しているかを確認することが重要です。

RHEL 9 / AlmaLinux 9 / Rocky Linux 9

Red Hat では kpatch を用いたカーネルライブパッチが標準提供されており、Kernel Live Patching サービスとして有効化できます。RHEL サブスクリプション（Standard/Premium）には含まれており、subscription-manager でリポジトリを有効にすることで利用できます。AlmaLinux・Rocky Linux については、RHEL 互換ではあるものの公式のライブパッチパッケージが提供されないバージョンがあるため、リポジトリの有無を事前に確認してください。

Ubuntu 22.04 LTS / 24.04 LTS

Canonical が提供する Canonical Livepatch が Ubuntu Pro サブスクリプションに含まれます。個人・小規模利用では最大5台まで無料枠が用意されており、ライセンスコストなしに試せます。pro attach <token> で有効化し、canonical-livepatch status で状態を確認します。Ubuntu 24.04（Noble Numbat）では対象CVEのカバー範囲が拡張されており、以前より幅広い脆弱性に対してライブパッチが提供されています。

openSUSE / SLES 15

KGraft ベースのライブパッチが SLES 向けに提供されています。SUSE Linux Enterprise Live Patching はアドオンとして有効化します。Debian や Fedora などのコミュニティディストリビューションでは公式のライブパッチサービスが提供されていないため、本番運用を前提とする場合は上記のディストリビューション選定が起点になります。

段階展開の設計：カナリア → 非クリティカル本番 → 全台

ライブパッチであっても「全台同時適用」は避けるべきです。パッチ自体のバグや特定ワークロードとの相性問題が稀に発生するためです。障害の爆発半径を最小化するため、通常のリリースと同様に段階展開を設計します。

ステージ1（カナリア）

本番と同等スペックのサーバー1〜2台（全体の5%程度）に最初に適用します。監視アラートのしきい値を通常より低く設定し、CPU使用率・レイテンシ・カーネルログに異常がないことを24時間以上確認します。この段階で問題が検出されれば、影響は最小範囲で封じ込められます。

ステージ2（非クリティカル本番）

バッチ処理ノード・DR系・ステージング相当の本番サーバー群など、影響が限定的なホストに拡大します。24〜48時間の観察期間を設けたうえで、問題なければ次ステージへ進みます。

ステージ3（本番全台）

残りのサーバーへ展開します。Ansible や Puppet などの構成管理ツールを使うと、ホストグループ単位でパッケージのインストールと適用状態の確認を一括制御しやすくなります。Ansible であれば yum モジュールで対象パッケージをインストールするだけでパッチが即時適用されるため、プレイブックの記述は単純です。

適用手順と検証（RHEL 9 / Ubuntu 24.04）

RHEL 9 での kpatch 適用

まず、Kernel Live Patching リポジトリが有効になっているか確認します。

subscription-manager repos --list-enabled | grep -i live

現在動作しているカーネルバージョンに対応するパッチパッケージを確認します。

uname -r
yum list available 'kpatch-patch-*'

対象バージョンのパッケージをインストールすると、パッチがカーネルに即時適用されます。

yum install kpatch-patch-<バージョン文字列>

適用状態は kpatch list で確認します。Loaded patches: の下にパッチ名が表示されれば成功です。カーネルモジュールとしても確認できます。

kpatch list
lsmod | grep kpatch

Ubuntu 24.04 での Canonical Livepatch 適用と確認

Ubuntu Pro アタッチ後、以下で詳細な状態を確認します。

canonical-livepatch status --verbose

Patch state: applied と表示されれば適用済みです。last check のタイムスタンプが古い場合は canonical-livepatch refresh で手動同期できます。適用対象のCVE番号も出力に含まれるため、問題のCVEが対象に含まれているかをここで確認します。

ロールバック設計と切り戻し手順

ライブパッチのロールバックは、通常のパッケージアップデートのロールバックより制約が多い点を理解しておく必要があります。

kpatch のアンロード

特定のパッチモジュールをアンロードするには以下を使います。

kpatch unload <patch-module-name>
yum remove kpatch-patch-<バージョン文字列>

ただし、パッチ適用後にパッチされた関数がアクティブに実行されている場合、kpatch unload は EBUSY を返して失敗します。この場合の確実な手段は再起動のみです。「ライブパッチのロールバックは再起動を許容する」という前提をインシデント対応手順に明記しておくことを推奨します。ライブパッチの目的は「問題が起きたときに再起動しない」ではなく、「問題がないときに再起動しない」です。

Ubuntu Livepatch の無効化

Canonical Livepatch では明示的なアンロードコマンドは提供されていないため、無効化には以下を使います。

canonical-livepatch disable

無効化後に問題が解消されるかを監視し、再有効化は canonical-livepatch enable で行います。いずれのディストリビューションも、ロールバック後は必ず dmesg と /var/log/kern.log（または journalctl -k）でカーネルログを確認し、エラーが残っていないかを検証してください。

運用上の注意点とよくあるつまずき

カーネルバージョンとパッチのミスマッチ

ライブパッチはカーネルバージョンに厳密に紐付いています。カーネルを更新した直後（再起動前）は旧バージョン向けのパッチが引き続き有効ですが、再起動して新バージョンで起動した後は、新バージョン向けのライブパッチを改めて適用する必要があります。一般的な自動化スクリプトでは、再起動後のカーネルバージョンを取得してパッチパッケージを再インストールするステップを含めておくと安全です。

Secure Boot 環境でのモジュール署名

RHEL 9 以降、Secure Boot 環境ではカーネルモジュールへの署名が要求されます。ベンダー提供の kpatch-patch パッケージはRed Hatの鍵で署名済みのため問題ありませんが、自前でビルドしたパッチは MOK（Machine Owner Key）による署名処理が別途必要です。本番環境で自前ビルドを使うケースは限定的ですが、テスト環境での動作確認時につまずくことがあります。

コンテナ・Kubernetes 環境との関係

DockerやPodman、Kubernetes上のコンテナはホストのカーネルを共有します。ホストにライブパッチを適用すれば、コンテナ内のプロセスにも適用されます。コンテナイメージ側でカーネルパッチを管理する必要はなく、ホスト単位での管理で完結します。ただし、EKSやGKEなどのマネージドKubernetesではノードのカーネル管理はプロバイダ側が担うため、ライブパッチの適用可否はプロバイダの仕様を確認してください。

CVEカバレッジの確認を省かない

ライブパッチが提供されるCVEの範囲はベンダーが決定します。すべてのカーネルCVEにライブパッチが提供されるわけではなく、特にドライバ層・ファイルシステム層の修正はライブパッチ対象外になることがあります。月次の対応では、問題のCVEに対してライブパッチが存在するかをベンダーの公式ナレッジベース（Red Hat CVEデータベース、Canonical CVEトラッカー等）で必ず確認してから段階展開の計画を立ててください。ライブパッチがないCVEについては、通常の再起動アップデートを速やかに実施する判断が必要になります。