Linuxカーネルの脆弱性が気になり、SSHで接続しているUbuntuサーバーの更新状態を確認した。すると、新しいカーネルはすでにインストールされていたのに、動いていたのは古いカーネルだった。
まず再起動で新しいカーネルに切り替え、続いてNode.jsなどの通常更新を適用した。更新後にも再起動が必要になり、今回は合計2回再起動している。その確認手順と、途中でつまずいたSSH・WSLの違いを残しておく。
作業日と公式情報の確認日は2026年10月30日。接続先のホスト名とユーザー名は説明用の値に置き換えている。以下のバージョンは今回の記録で、実際に更新するときはその時点の配信状況を確認する。
今回の環境と結果
| 項目 | 作業前 | 作業後 |
|---|---|---|
| Ubuntuの表示 | 24.04.3 LTS | 24.04.5 LTS |
| 稼働中のカーネル | 6.8.0-107-generic |
6.8.0-147-generic |
| Node.js | 22.22.0 |
22.23.4 |
| 通常の更新候補 | 100件以上 | 0件 |
| systemdの失敗サービス | 作業前は未確認 | 0件 |
| 再起動通知 | 作業前は未確認 | 最後の再起動後は表示なし |
手元のPCはWSL2で、そこからサーバーへSSH接続した。サーバーではAPTによるパッケージ管理を利用し、管理作業にはsudoを使っている。
今回は同じUbuntu 24.04 LTSの中で更新した。ログイン時に案内された26.04へのリリースアップグレードは行っていない。
サーバーのOSと稼働中のカーネルを確認する
まず、手元のPCからサーバーへ接続する。userとserver.example.comは自分の接続先に置き換える。
ssh [email protected]
接続先のサーバーで、次を実行した。
cat /etc/os-release
uname -r
/etc/os-releaseはOSの種類とバージョン、uname -rは現在動いているカーネルを確認するためのもの。今回の出力を抜粋すると、次の状態だった。
PRETTY_NAME="Ubuntu 24.04.3 LTS"
VERSION_ID="24.04"
VERSION_CODENAME=noble
6.8.0-107-generic
Ubuntuのバージョンとカーネルのバージョンは別の情報なので、両方を確認しておく。
インストール済み・更新候補・稼働中を比べる
続いて、パッケージ情報を取得し、カーネルの更新候補とファイルを確認した。
sudo apt update
apt-cache policy linux-image-generic
ls /boot/vmlinuz-*
apt updateは配布元からパッケージ情報を取得する操作。パッケージ本体の更新には、後述するapt upgradeを使う。Ubuntu公式のパッケージ管理手順
apt-cache policyの出力は、次のようになっていた。配布元などの行は省略している。
linux-image-generic:
Installed: 6.8.0-147.147
Candidate: 6.8.0-147.147
/bootには、古いものと新しいものの両方があった。
/boot/vmlinuz-6.8.0-107-generic
/boot/vmlinuz-6.8.0-147-generic
| 表示 | 今回確認したこと |
|---|---|
Installed |
linux-image-genericの導入済みバージョンは6.8.0-147.147 |
Candidate |
配布元から選ばれる候補も6.8.0-147.147 |
/boot/vmlinuz-* |
新しい6.8.0-147のカーネルファイルが存在する |
uname -r |
それでも稼働中なのは6.8.0-107-generic |
linux-image-genericは、対応するカーネルパッケージを導入するためのメタパッケージ。新しいカーネルが入っていることと、それで起動していることは別だった。Ubuntuの公式資料でも、新しくインストールしたカーネルで動かすには再起動が必要と説明されている。Livepatchによる稼働中のカーネルへの修正適用は別の仕組みで、今回はその適用状況までは確認していない。Ubuntu公式のカーネル解説
1回目の再起動で新しいカーネルに切り替える
サーバーを再起動した。実行するとSSH接続も切れ、サーバー上のサービスは一時停止するので、停止できるタイミングで行う。
sudo reboot
再起動直後のConnection refused
再起動してすぐにSSHで接続し直したところ、接続が拒否された。接続先を説明用に置き換えると、次のエラーになる。
ssh: connect to host server.example.com port 22: Connection refused
今回は少し待ってから再接続するとログインできた。再起動直後はSSHがまだ接続を受け付けていない可能性がある。ただし、このエラーだけで再起動中と断定はできない。数分待っても続く場合は、サーバーの管理画面やコンソールから起動状態とSSHサービスを確認する。
SSHが切れたあとは手元のPCに戻っている
このとき、接続できていないまま手元のターミナルでuname -rを実行してしまった。
6.6.87.2-microsoft-standard-WSL2
これは手元のWSL2のカーネルだった。サーバーの再起動結果を調べるには、SSHでサーバーへ入り直してからコマンドを実行する必要がある。
| 実行する場所 | 実行すること |
|---|---|
| 手元のPC・WSL | ssh [email protected]で接続する |
| SSH接続先のサーバー | uname -rでサーバーのカーネルを確認する |
再接続後、サーバーで実行した。
uname -r
6.8.0-147-generic
これで新しいカーネルに切り替わった。6.8.0-147-genericはコマンドの出力なので、それ自体を入力する必要はない。
残っているパッケージの更新を適用する
カーネルを切り替えたあと、ほかにも更新候補が残っていたので一覧を確認した。
apt list --upgradable
今回の一覧には、次のようなパッケージが含まれていた。
| 対象 | 一覧で確認した内容 |
|---|---|
| Node.js | 22.22.0から22.23.4への更新 |
| PHP関連 | php-commonと画像処理ライブラリのlibgd3の更新 |
| OS関連 | AppArmor、Netplan、起動関連パッケージ、各種ライブラリなど |
Node.js 22.23.4は、2026年10月21日公開のセキュリティリリース。TLSやDNS処理、Brotliなどの修正を含む。Node.js公式リリースノート
PHP本体のphp8.x-cliやphp8.x-fpmの更新は、この一覧にはなかった。php-commonの更新だけでは、PHP本体やWeb側で稼働しているPHPのバージョンまで確認したことにはならない。
一覧を確認したあと、サーバー側で通常の更新を実行した。
sudo apt upgrade
最初のDo you want to continue? [Y/n]で内容を確認して進める。Ubuntu 24.04では、更新されたライブラリを利用するサービスがneedrestartによって自動再起動される場合もある。Ubuntu公式のサービス再起動の説明
キーボード配列の設定画面が出た
途中でConfiguring keyboard-configurationという画面が開いた。日本語配列向けの選択肢として、一番上に通常のJapanese、その下にDvorakやKanaなどの種類が並んでいた。
日本語配列の環境では通常のJapaneseを選び、Tabで<Ok>へ移動し、Enterで確定して進める。別の配列を使っている場合は、その環境に対応するものを選ぶ。
更新後の確認と2回目の再起動
更新処理が終わったあと、サーバー側で次の4つを実行した。
node -v
apt list --upgradable
systemctl --failed --no-pager
cat /var/run/reboot-required 2>/dev/null
| 確認項目 | 更新直後の結果 |
|---|---|
node -v |
v22.23.4 |
apt list --upgradable |
Listing... Doneだけで、更新候補の行はなし |
systemctl --failed --no-pager |
0 loaded units listed. |
| 再起動通知 | *** System restart required *** |
パッケージの更新は終わっていても、再起動が必要という通知が残っていた。そのため、もう一度サーバーを再起動した。
sudo reboot
少し待ち、手元のPCから再び接続した。
ssh [email protected]
再接続後のログイン表示は、次の状態になっていた。
Ubuntu 24.04.5 LTS (GNU/Linux 6.8.0-147-generic x86_64)
0 updates can be applied immediately.
さらに、サーバー側で失敗サービスと再起動通知を確認した。
systemctl --failed --no-pager
cat /var/run/reboot-required 2>/dev/null
失敗サービスは再び0 loaded units listed.。再起動通知のコマンドは何も表示しなくなった。2>/dev/nullはエラー出力を表示しない指定で、通知ファイルが存在しない場合のメッセージも隠している。
今回の記録では、SSHで再接続でき、失敗状態のsystemdサービスと再起動通知が残っていないことまで確認できた。Webアプリのページ表示、ログイン、DBを使う操作などは、これらとは別に確認する必要がある。この記録には、公開サイトの動作確認結果は含めていない。
通常更新が0件でも、残っている対応がある
今回関係するカーネル脆弱性の代表例を、Ubuntu公式の情報と照合した。
| 脆弱性 | Ubuntu 24.04の標準カーネル向けの状況(2026年10月30日確認) |
|---|---|
| PPPoEject・CVE-2026-68121 | 6.8.0-147.147で修正済み。今回起動したカーネルに修正が含まれる。Ubuntu公式 |
| TCP/IPv4・CVE-2026-98432 | 修正準備中。公式ページには6.8.0-149.149で作業中とあり、今回の6.8.0-147では未修正。Ubuntu公式 |
また、最後のログイン時にも次の案内が残っていた。
Expanded Security Maintenance for Applications is not enabled.
17 additional security updates can be applied with ESM Apps.
ESM Appsは、Ubuntu Proで提供される追加のセキュリティ更新で、universeのパッケージを対象とする。今回は有効化しておらず、この17件は通常更新に含まれていない。対象パッケージやCVEの内訳までは今回確認していない。Ubuntu公式のESM解説
今回完了したのは、有効な配布元から通常適用できるパッケージ更新と、その反映のための再起動・状態確認。今後も更新候補を確認し、修正準備中のカーネル脆弱性は配信後に対応する。ESM Appsの追加更新については、対象パッケージと利用状況を別途確認する。