ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux情報・技術・セキュリティ ＞ livepatchを当てた後の運用設計｜2026年5月Linuxカーネル LPEラッシュで現場が学んだ累積管理と再起動移行
この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
livepatch は便利ですが、 「当てたら終わり」と思って累積で何枚も乗せ続けると、ある日突然ロード失敗・副作用・再起動時に何が変わるか読めない状態に追い込まれます。私が20年以上Linuxサーバーを運用してきて、livepatch で起きた事故はほぼすべて 「累積管理を怠った」「再起動移行を後回しにした」の2パターンに集約されます。
この記事は、 CVE個別の解説ではなく、livepatchを当てた後に必ず通る道——累積パッチの可視化、ロード失敗時の切り戻し、計画再起動への合流——を実務手順として整理します。CVE-2026-46333 / CVE-2026-46300 の 仕様や攻撃手法については別記事で扱っていますので、必要なら本文中の関連リンクからどうぞ。
この記事のポイント
- livepatch / kpatch / KernelCare で稼働中にカーネルパッチを適用したサーバーは、 「何枚積んだか」「いつ再起動するか」を台帳化するのが大前提。
- 累積上限の目安: Canonical Livepatch / kpatch / KernelCare のいずれも明示上限はないが、 四半期ごとに棚卸し、半年で再起動到達が現場の運用ライン。
- ロード失敗時の切り戻しは livepatch disable → 再起動 → 通常カーネル適用の順。手順を運用書に固定しておくと事故率が下がる。
- 再起動移行は「いつ」より「どの順番で」を決める。 冗長構成 → 単独本番 → 踏み台の順が安全。
- 緊急パッチ後の振り返り定例（postmortem）を 3日以内に回すと、次回の判断が速くなる。
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／
詳細はこちら
livepatchを「当てた直後」にやる3つの記録
緊急パッチを livepatch で当てた直後は 記録が薄くなりがちです。攻撃の止血で頭が一杯になっていて、適用後の確認や台帳化を後回しにする。これがあとで効いてきます。最低限、当日中に次の3つは記録します。
| 項目 | コマンド例 | 何を残すか |
|---|---|---|
| 適用前カーネル | uname -r | 切り戻し時の戻り先 |
| 適用済みlivepatch | canonical-livepatch status --verbose / kpatch list / kcarectl --info | どのCVEのパッチが乗っているか |
| 適用日時とCVE | 適用直後にtee /var/log/livepatch-ledger.log | 運用台帳化 |
社内に運用ドキュメントツールがあるならそこに転記、なくても サーバーローカルに `livepatch-ledger.log` を置いておくだけで、3ヶ月後の自分が必ず助かります。
累積上限の目安とライセンス毎の挙動
livepatch 系3製品はいずれも 「累積枚数の明示上限」をドキュメント化していません。これが運用上やっかいで、「いつまで積めるか」を自分で決める必要があります。| 製品 | 累積方式 | 運用上のライン |
|---|---|---|
| Canonical Livepatch | 1モジュールに統合してロード | 四半期で1回は次のカーネルABIに移行 |
| Red Hat kpatch | kABI互換維持、累積パッチRPMを上書き | EUS切替時に必ず再起動 |
| KernelCare | 累積パッチイメージを差し替え | 年1回はreboot推奨（公式コラム） |
私の運用ラインは 「四半期に1回は再起動を計画、半年経ったら強制再起動」です。半年放置すると、livepatch が積み上がっているのか、次の再起動で何が変わるのかが運用側で把握しきれなくなる。台帳に書いていても、3ヶ月以上前のメモは そのときの判断理由まで思い出せないので、半年が運用上の限界線です。
ロード失敗時の切り戻しプレイブック
失敗パターンは3つ
livepatch のロード失敗には大きく3パターンあります。- 署名検証エラー: 配信フィードの鍵更新や、SecureBoot との競合で発生
- シンボル解決エラー: カーネル本体側で構造体やシンボルが変わり、累積パッチがマッチしない
- パニック・OOPS: ロード自体は成功するが、稼働中に kernel panic / OOPS で落ちる
1番目と2番目は 適用前に検知できるので、適用ログを必ず確認します。3番目は最も怖いケースで、ロード成功＝動くとは限らない。
切り戻し手順
切り戻しは「livepatchを無効化 → 再起動 → 通常カーネルに合流」の3ステップです。# Canonical Livepatch
sudo canonical-livepatch disable
sudo reboot
sudo apt update && sudo apt upgrade linux-image-generic
sudo reboot
# Red Hat kpatch
sudo kpatch unload --all
sudo reboot
sudo dnf upgrade kernel
sudo reboot
# KernelCare
sudo kcarectl --unload
sudo reboot
sudo dnf upgrade kernel
sudo rebootここで重要なのは 「再起動2回」になること。1回目で livepatch を剥がし、2回目で通常カーネルを反映します。サービス停止時間が読みにくいので、 切り戻しは原則メンテナンス枠で計画実施します。緊急避難の場合は冗長構成の片肺で切り戻し検証→もう片肺へ展開、という二段構えが安全です。
再起動移行は「順番」で決める
livepatch を当てた後の 計画再起動の段取りは、「いつやるか」より「どの順番でやるか」を決めるほうが現場では効きます。私の現場ルールは次の順番です。| 順番 | 対象サーバー | 理由 |
|---|---|---|
| 1番目 | 冗長構成の片肺（LB配下・クラスタ） | サービス無停止で再起動検証できる |
| 2番目 | 同冗長構成のもう片肺 | 1番目の結果を見て安全に展開 |
| 3番目 | 単独本番（DB主・APIゲートウェイ） | 停止枠を取って計画停止 |
| 4番目 | 踏み台・管理サーバー | 本番影響後に作業端末を更新 |
踏み台を 最初に再起動する現場をたまに見ますが、これは危険です。踏み台が落ちている間に本番で何か起きたとき、リモート復旧手段がなくなる。本番が全部安定してから踏み台を当てるのが正解です。
緊急パッチ後の振り返りを3日以内に回す
緊急パッチ対応のあと、 3日以内に振り返り定例（postmortem）を1回入れると、次回の判断スピードが目に見えて上がります。記憶が新しいうちに、次の5項目だけ残します。- 初動の遅延要因: 検知から適用判断まで何分／何時間かかったか、ボトルネックはどこか
- 暫定緩和の選択: ptrace_scope 引き上げ・SUID剥離・sysctl 変更などのどれを使ったか、副作用は出たか
- 適用経路: livepatch / kpatch / KernelCare / 通常更新+再起動のどれを使ったか、なぜそれを選んだか
- 事後対応: SSHホスト鍵ローテーション・パスワード強制更新を実施したか、しなかったならなぜ
- 次回への申し送り: 同種CVEが来たら何を変えるか、運用書に追記すべき項目はあるか
これを社内Wikiでもテキストファイルでも構わないので、 1ファイル30分で書き留めるだけ。次のCVEラッシュ（必ず来ます）で、自分と組織の判断スピードが変わります。
個別CVEの仕様は別記事で
本記事ではあえて個別CVEの脆弱性詳細には踏み込みませんでした。2026年5月の Linux カーネル LPE ラッシュの中身については、当サイトの別記事を参照してください。CVE単発の解説と、本記事のような 運用フェーズの段取り記事は、補完関係です。同種のカーネル脆弱性は今後も繰り返し出るので、「個別CVEを読む → 運用プレイブックに落とす」という流れを自分の現場で固定化しておくと、次のラッシュで慌てなくて済みます。
よくある質問（FAQ）
Q1. livepatch を当てた後、いつまで再起動を引っ張っていいか？
製品ドキュメントには明示上限はありませんが、 四半期で1回は計画、半年で強制再起動が現実的なラインです。半年を超えると、livepatch の中身と次の再起動で起きることが運用側で把握できなくなります。Q2. livepatch がロード失敗したとき、即座に切り戻すべきか？
ロード失敗 そのものは脆弱性が塞がっていない状態なので即対応が必要です。ただし切り戻し（livepatch 無効化＋通常更新）は再起動2回が必要なので、 冗長構成があるなら片肺で先行検証してから本格適用。冗長なしならメンテナンス枠で計画実施します。Q3. KernelCare の「年1回 reboot 推奨」は厳しすぎないか？
KernelCare の公式コラム上の推奨で、運用現場では 四半期ごとの計画再起動に統合してしまうのが現実的です。年1回だと、その「1回」を逃したときの累積リスクが大きくなる。短いサイクルで小さく再起動するほうがトラブルシュートも楽です。Q4. 踏み台を最後に再起動する理由は何か？
本番の再起動で問題が起きたとき、 踏み台が動いているうちにリモート復旧できる必要があるからです。踏み台を最初に当ててしまうと、本番側の障害時に作業端末がない状況に追い込まれます。踏み台は 本番全部の動作確認が終わったあとに最後に再起動するのが鉄則です。Q5. 振り返り定例を3日以内に回す理由は？
人間の記憶は3日でかなり薄くなります。 初動の遅延要因や暫定緩和の選択理由は、当日中なら細かいニュアンスまで覚えていますが、1週間経つと「なぜそうしたか」を再構成できなくなる。3日以内に書けば、次回CVEラッシュで 「前回はこれで失敗した」という具体的判断材料が残ります。2026年5月の Linux カーネル LPE ラッシュは、CVE仕様の難度より 運用判断の連続性が問われた事案でした。livepatch を当てたあと、台帳化・累積管理・計画再起動・振り返りまで含めて初めて「対応完了」。私の20年以上の現場経験で、 パッチ運用で本当に強い現場は、緊急時の即応より平時の運用設計が固い現場です。
Linuxの実務スキルを体系的に学びたい方は、リナックスマスター.JPの無料メルマガをご検討ください。
平日毎朝、Linux運用・セキュリティ・キャリアの3軸で「現場で本当に使える」情報をお届けします。
暗記不要・1時間後にはサーバーが動く
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
Linux無料マニュアル（図解60P）
名前とメールで30秒登録
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：GitLab 18.11.3で25件のCVEを塞ぐ｜self-managed omnibus-gitlabのアップグレード実務
- 前のページへ：バックエンドエンジニア年収923万円｜Linuxスキル保有者が年収レンジで優位に立つ条件
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます