カーネルをリブートせずにパッチ適用する｜kpatchとLivepatchの選択基準と本番での判断軸

カーネルの脆弱性が公開されるたびに、本番サーバーを一斉に再起動するのは現実的ではありません。24時間稼働のサービスや計画停止ウィンドウが限られる環境では、リブートなしにカーネルパッチを適用できる「ライブカーネルパッチング」が重要な選択肢になっています。本記事では、代表的な実装であるkpatchとCanonical Livepatchの仕組みと選択基準、そして本番適用における判断軸を整理します。

ライブパッチングが求められる背景

Linuxカーネルの脆弱性は毎年数十件以上がCVEとして登録されます。その中でもCVSSスコア7以上の高リスク案件は、公開から数日以内にPoC（概念実証コード）が出回るケースも少なくありません。従来の対応フローは「パッケージアップデート → 再起動 → 動作確認」が基本でしたが、これには複数の課題があります。

• データベースやキューイングシステムは再起動コストが高く、計画停止の調整に数日かかることがある
• 複数リージョンにまたがるサーバー群を順次リブートする間、パッチ未適用のノードが混在し続ける
• コンテナホストでは、ホストカーネルのリブートがすべてのコンテナ停止を意味する

こうした状況を背景に、実行中のカーネルにパッチを当てたまま稼働を継続できるライブパッチング技術が実用段階に入り、主要ディストリビューションで標準的にサポートされるようになりました。

ライブカーネルパッチングの仕組み

ライブカーネルパッチングの基本的な原理は、動作中のカーネル関数を新しい実装に差し替えることです。Linuxカーネル4.0以降に取り込まれたlivepatchサブシステムが共通基盤となっており、各ディストリビューションはこの仕組みの上に独自のパッチ配信インフラを乗せています。

実際のパッチ適用は「ftrace」フックを使って脆弱な関数の先頭に分岐を挿入し、修正済みの関数へリダイレクトするという手順で行われます。カーネル空間の既存コードを書き換えるのではなく、新しいコードモジュールをロードして関数テーブルを差し替える形になるため、理論上はカーネルのコアコードを保ったまま安全に切り替えが可能です。

kpatch（Red Hat / Fedora系）

kpatchはRed Hatが開発し、OSSとして公開しているライブパッチングフレームワークです。RHEL 7以降および対応Fedoraバージョンでサポートされており、Red Hat公式の「kpatch-patch」パッケージとして脆弱性対応済みパッチが配信されます。オンプレミスのRHELサブスクリプション環境ではそのままdnf経由で適用でき、追加コストは発生しません。

Canonical Livepatch（Ubuntu系）

CanonicalはUbuntu向けに「Canonical Livepatch Service」を提供しています。Ubuntu Proサブスクリプション（個人利用は5台まで無償）に含まれており、canonical-livepatchデーモンがクラウドからパッチを自動取得・適用します。コマンド1本でデーモンを有効化でき、運用の自動化が容易な点が特徴です。

SLE Live Patching（SUSE系）

SUSEはSLE（SUSE Linux Enterprise）向けに「SUSE Linux Enterprise Live Patching」を提供しています。こちらはSUSE独自のkGraft技術を起源としており、現在はアップストリームのlivepatchと統合されています。商用サポートが必要なエンタープライズ環境向けの位置づけです。

kpatch と Livepatch の選択基準

どちらを選ぶかは、まずディストリビューションの選択によって自然に決まります。RHELまたはそのクローン（AlmaLinux・Rocky Linux）を使っているならkpatch系、Ubuntuを使っているならCanonical Livepatchが対応する選択肢です。両者を横断して比較する場面は、OSを新規選定するときに限られます。

ただし、いくつかの軸で検討の余地があります。

• パッチ配信のタイミング： Canonical Livepatchはカーネルリリースから比較的短期間でパッチが配信される傾向にあります。kpatchはRed Hatのリリースサイクルに依存するため、RHEL系では配信タイミングが遅れるケースもあります。Critical CVEへの対応速度を重視する場合は事前に確認が必要です。
• 自動適用の可否： Canonical Livepatchはデーモンが定期ポーリングして自動適用するモデルです。kpatchはdnfの自動更新と組み合わせることで同様の挙動を実現できますが、設定は明示的に行う必要があります。変更管理プロセスが厳格な環境では自動適用を無効にして手動制御したほうが運用事故を防ぎやすい場面もあります。
• カバレッジ（対応CVEの範囲）： 両者ともすべてのCVEをライブパッチで対応しているわけではありません。複雑なデータ構造変更を伴うパッチや、カーネルの広範な領域に影響する修正はライブパッチとして提供されないことがあり、その場合は通常のリブートを伴うアップデートが必要です。

本番環境での適用手順

手順の詳細はディストリビューションによって異なりますが、共通して踏むべきステップは変わりません。

kpatch の適用手順（RHEL系）

まず現在のカーネルバージョンを確認します。uname -r の出力に対応したkpatch-patchパッケージが存在するかをdnf list kpatch-patch-*で確認できます。対応パッケージが存在すればdnf installでインストールするだけでパッチが即座に適用されます。適用後はkpatch listで読み込み済みパッチモジュールの一覧が確認できます。

再起動後も有効にするにはkpatchモジュールをsystemdサービスとして登録する必要があります。kpatch installサブコマンドがこの登録を行い、次回ブート時に自動ロードされるよう/etc/systemd/system/にサービスユニットを配置します。

Canonical Livepatch の適用手順（Ubuntu）

Ubuntu Proのトークン取得後、pro attach <token>でサブスクリプションをアクティベートし、pro enable livepatchでサービスを有効化します。これだけでcanonical-livepatchデーモンが起動し、クラウドから対応パッチを取得して自動適用するようになります。現在の適用状態はcanonical-livepatch status --verboseで確認できます。

適用後の検証と切り戻しの考え方

ライブパッチングは「リブートなし」がメリットですが、検証を省略してよい理由にはなりません。適用後の確認として以下の観点を押さえておくことが重要です。

• パッチの読み込み確認： kpatchならkpatch list、Livepatchならcanonical-livepatch statusで「applied」または「nothing-to-apply」以外のエラー状態が出ていないかを確認します。
• カーネルログの確認： dmesg | grep -i livepatchでパッチのロード時にエラーメッセージが出ていないかを確認します。
• アプリケーションの動作確認： ライブパッチ適用直後にサービスの応答時間やエラーレートが変化していないかを監視ツールで確認します。

切り戻しについては、ライブパッチングはモジュールのアンロードによって理論上は元の状態に戻せますが、すべてのパッチがアンロードに対応しているとは限りません。kpatchではkpatch unload <module>でモジュールをアンロードできますが、カーネル内の状態遷移によっては安全にアンロードできないと判断されてエラーになるケースもあります。

現場での現実的な切り戻し手順は「ライブパッチを無効化した上で次回ブート時に旧カーネルを選択する」というリブートを伴うものになることが多く、ライブパッチングが「リブートを完全に不要にする」という意味ではなく「リブートを先送りにして対応速度を確保する」という位置づけであることを理解しておく必要があります。

2026年現在の環境差分と運用上の注意点

2026年時点でライブパッチングを取り巻く環境はいくつかの点で変化しています。

Ubuntu Proの無償枠拡大： Canonical Livepatchを含むUbuntu Proは、以前は有償のみでしたが、個人・小規模利用向けに1アカウントあたり5台まで無償で利用できるようになっています。これにより、商用サービスではないシステムでもLivepatchを評価・導入しやすくなっています。

RHEL互換ディストリビューションでのkpatch対応： AlmaLinuxやRocky Linuxなどのコミュニティ主体のRHEL互換ディストリビューションでは、RHELと同等のkpatch-patchパッケージが提供されているケースと、独自のライブパッチ配信が整備されていないケースがあります。AlmaLinuxはCVEパッチの提供を進めていますが、配信タイミングやカバレッジはRHELと差がある点に注意が必要です。Rocky Linuxでも同様の動きがありますが、2026年8月時点では自前のkpatchパッケージインフラの整備状況をプロジェクトのリリースノートで個別に確認することを推奨します。

クラウドネイティブ環境での位置づけ： コンテナワークロードが主流になった現在、カーネルのライブパッチングはコンテナホスト（ベアメタルまたはVM）の管理に絞って適用されるケースが増えています。コンテナそのものはカーネルを共有するため、ホストのカーネルにパッチを当てることでコンテナ内のワークロードも保護されます。一方でKubernetesのノードプールを滑走させながらローリングリブートするアプローチが普及しており、これによってライブパッチングの必要性がそもそも低下している環境もあります。どちらを選ぶかは、ノードのローリング交換が容易なクラウドマネージド環境か、長期稼働のベアメタルが主体の環境かによって判断が分かれます。

カーネルバージョンの固定とサポート期間： ライブパッチングのパッチは特定のカーネルバージョンに紐付いているため、カーネルを頻繁にアップグレードするポリシーと相性が悪い面があります。LTSカーネルやディストリビューションのサポートライフサイクルを意識してカーネルバージョンを固定し、その期間内はライブパッチングで対応するという運用が現実的です。

ライブカーネルパッチングはあくまでも時間を稼ぐ技術であり、計画的なカーネルアップデートとリブートを完全に置き換えるものではありません。脆弱性の公開から対応完了までのリードタイムを短縮しつつ、次回の計画停止ウィンドウまでサービスを安定稼働させるための手段として位置づけることが、実務での正しい使い方といえます。