第933回：Ubuntu 如何確認是否已修復特定 CVE
第933回 Ubuntuが特定のCVEに対応できているかの確認方法
文章介紹在 Ubuntu 上檢查特定 CVE 修復狀態的方法，包括以 `pro fix --dry-run` 查詢單一漏洞，以及用 OpenSCAP 配合 Ubuntu OVAL 數據檢查多項漏洞。
AIの進化とともに、発見・報告される脆弱性の数が増え、攻撃可能になるまでの期間がどんどん短くなっています。その結果、日々の業務において手元のOSやコンテナイメージ等の確認に追われている方も多いことでしょう。今回はUbuntuシステムにおいて、簡単に脆弱性状況を確認する手段をいくつか紹介します。
UbuntuにおけるCVE番号とUSN番号について
何らかの脆弱性やその候補が発見されると、状況に応じてCVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）番号が割り振られます[1]。セキュリティ担当者は日々このCVE（やそれに類する情報）をチェックし、影響範囲や対策の要否を精査し、システムを更新し続けています。その際に、このCVE番号（など）がある種の「識別子」として使われるのです[2]。
CVE番号に紐づいた脆弱性の詳細が公開されるタイミングはまちまちです。基本的にはソフトウェア側の対応の準備が整い、各種サーバーへと適用できるようになってから公開されるのが理想です。しかしながら人の口に戸は立てられません。悪意があるかどうかに関係なく漏れてしまうことは多々あります。
さらに最近は人の口以前にAIの手に枷がかけられず、戸を立てる暇すらなくなっています。自発的に脆弱性を見つけて、攻撃手段まで用意してくれます。そのため「脆弱性の詳細が公開されたからシステムを更新する」だけでは間に合わないことも増えてきました。システムごとのセキュリティアドバイザリーをチェックしつつ、緩和策があればそれを適用し、対応版パッケージが公開されたら適用するサイクルをより早く回さなければならなくなったのです。
Ubuntuでは、さまざまな情報元から提供された修正情報やそれに付随するCVE番号を元に、Ubuntuに影響しそうな番号を「Ubuntu CVE Tracker」に登録します。登録されたCVE番号については、必要に応じて特定のパッケージ情報と紐づけたり、公開された情報を拡充したりしていきます。これらの情報をまとめて閲覧できるのが「CVE reports」です。ここにはリリースごとの影響の有無や修正パッケージの対応状況などが随時反映されます。「https://ubuntu.com/security/＜CVE番号＞」のURLで参照できるため、特定のCVE番号についてのUbuntuの状況を確認したり、相手へ伝えたい場合に役立つでしょう。
CVE reportsに掲載された時点でパッケージが修正されているとはかぎりません。最終的にパッケージが修正されて、インストールできるようになったタイミングで発行されるのが「Ubuntu Security Notices（USNs）」です。ここではCVE番号とは異なる体系で採番されます。これはひとつのパッケージの更新によって複数のCVE番号に対応していることもあるためです。USNのページではリリースごとの修正パッケージバージョンが記載されています[3]。
そのためUbuntuマシンを管理する上では、CVE番号に紐づいたパッケージのバージョンもしくはUSNを確認しなくてはなりませんし、それが公開されているかどうかをチェックする必要があります。これが大変です。
proコマンドでパッケージレベルの対応状況を確認する
CVE番号に対するUbuntuの対応状況を確認する上で最も簡単な手段が「proコマンドの利用」です。これはUbuntuのサポートサービスである「Ubuntu Pro」を利用するためのツールではありますが、Ubuntu Proに加入しなくても利用できます。
たとえば最近深刻度が変更されて話題になった「CVE-2026-98432」について確認すると、次のように表示されます。
$ pro fix --dry-run CVE-2026-98432
WARNING: The option --dry-run is being used.
No packages will be installed when running this command.
CVE-2026-98432:
In the Linux kernel, the following vulnerability has been resolved:
ipv4: free inet_opt and ireq_opt after an RCU grace period
tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the
child socket (newinet->inet_opt) without copying it.
Another cpu can concurrently process a retransmitted SYN for the same
request socket, and send a SYNACK from tcp_check_req().
tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt
under rcu_read_lock() only, and ip_build_and_send_pkt() and
ip_options_build() then read opt->optlen twice.
Note that the SYNACK timer itself is not an issue: it holds a
reference on its request socket, and inet_csk_reqsk_queue_drop()
calls timer_delete_sync() before the child can be freed.
Since commit 079096f103fa ("tcp/dccp: install syn_recv requests
into ehash table"), request sockets are processed without holding
the listener lock, so nothing prevents the child socket from being
freed while the SYNACK is still being built. TCP child sockets do
not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt
with a plain kfree(), leading to a use-after-free in
ip_options_build().
A similar issue exists with request socket migration
(net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE
program). reqsk_timer_handler() clones the request socket with
inet_reqsk_clone(), so that the old request socket and its clone
share the same ireq_opt, then reqsk_migrate_reset() clears the
pointer in the old one. Another cpu holding a reference on the old
request socket can still be using these options (sending a SYNACK,
or creating a child in tcp_v4_syn_recv_sock()) when the clone is
freed, and tcp_v4_reqsk_destructor() also uses a plain kfree().
Readers already use RCU, and other paths replacing inet_opt
(do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use
kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and
tcp_v4_reqsk_destructor() as well.
IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock()
duplicates the options. tcp_v6_reqsk_destructor() has the same
migration issue with ipv6_opt, which is only set by CALIPSO. This
will be addressed in a separate patch.
- https://ubuntu.com/security/CVE-2026-98432
1 affected source package is installed: linux
(1/1) linux:
A fix is coming soon. Try again tomorrow.
1 package is still affected: linux
✘ CVE-2026-98432 is not resolved.
「pro fix」は「特定のCVE番号もしくはUSN番号の修正を適用する」ためのコマンドです。「fixした結果」の戻り値として次の値が用意されています。
- 0：修正を適用済み（already fixed）かシステムには影響しない（not affected）状態
- 1：修正がまだ用意されていないか適用されていない（not resolved）状態
- 2：修正は適用されたが再起動が必要な状態
上記の例ですと「A fix is coming soon」と表示されていますので、linuxパッケージ（カーネルパッケージ）に影響するものの、まだ修正パッケージが用意されていないのだとわかります。この状態でパッケージを更新したところで、修正パッケージはインストールされません。
ちなみに「--dry-run」を指定することで、修正を試みた結果だけを確認します。「--dry-run」なしで実行すると、このCVE/USN番号の対応に必要なパッケージが存在する場合、その更新を試みますので注意してください。また「試みた」と書いているように「現在の状態」ではなく、「パッケージを更新した結果」を報告している点に注意が必要です。
もう少し具体的な例を示しましょう。CVE-2026-111497はデータ圧縮ライブラリに関する脆弱性です。Ubuntu 26.04 LTSでは「1.2.0-3build1」までは脆弱性が存在し、「1.2.0-3ubuntu0.1」で修正されました。
ここで古い「1.2.0-3build1」がインストールされている環境で確認してみましょう。
$ apt policy libbrotli1
libbrotli1:
Installed: 1.2.0-3build1 <= 古いほうがインストールされている
Candidate: 1.2.0-3ubuntu0.1
Version table:
1.2.0-3ubuntu0.1 500
500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
*** 1.2.0-3build1 500
500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages
100 /var/lib/dpkg/status
$ pro fix --dry-run CVE-2026-111497
WARNING: The option --dry-run is being used.
No packages will be installed when running this command.
CVE-2026-111497: Brotli vulnerability
- https://ubuntu.com/security/CVE-2026-111497
1 affected source package is installed: brotli
(1/1) brotli:
A fix is available in Ubuntu standard updates.
{ apt update && apt install --only-upgrade -y libbrotli1 }
✔ CVE-2026-111497 is resolved.
古いほうがインストールされているにも関わらず、「CVE-2026-111497 is resolved」と表示されてしまいました。これはその2行前の「apt install --only-upgrade -y libbrotli1」を実行した結果としてどうなるかを表示しているためです。
試しに「--dry-runなし」で実行してみましょう。
$ pro fix CVE-2026-111497 CVE-2026-111497: Brotli vulnerability - https://ubuntu.com/security/CVE-2026-111497 1 affected source package is installed: brotli (1/1) brotli: A fix is available in Ubuntu standard updates. Package fixes cannot be installed. To install them, run this command as root (try using sudo) 1 package is still affected: brotli ✘ CVE-2026-111497 is not resolved.
修正を試みようとするものの管理者権限がなく、インストールできませんでした。その結果として「CVE-2026-111497 is not resolved」となります。次は管理者権限ありで実行してみます。
$ sudo pro fix CVE-2026-111497
CVE-2026-111497: Brotli vulnerability
- https://ubuntu.com/security/CVE-2026-111497
1 affected source package is installed: brotli
(1/1) brotli:
A fix is available in Ubuntu standard updates.
{ apt update && apt install --only-upgrade -y libbrotli1 }
✔ CVE-2026-111497 is resolved.
パッケージの更新が実行されて、無事にlibbrotli1パッケージは対応版になったようです。この状態でさらにもう一度「--dry-run」を実行してみます。
$ pro fix --dry-run CVE-2026-111497 WARNING: The option --dry-run is being used. No packages will be installed when running this command. CVE-2026-111497: Brotli vulnerability - https://ubuntu.com/security/CVE-2026-111497 1 affected source package is installed: brotli (1/1) brotli: A fix is available in Ubuntu standard updates. The update is already installed. ✔ CVE-2026-111497 is resolved.
パッケージ更新前と同じく「CVE-2026-111497 is resolved」と表示されます。ここで注意すべきは下から3行目です。「The update is already installed」と表示されるようになりました。つまり「pro fix --dry-run」を実行したときの出力は、次の方法で比較する必要があります。
- 「A fix is coming soon. Try again tomorrow」を表示：修正は必要だがまだパッケージは用意されていない
- パッケージのインストール手順を表示：修正パッケージは提供済みで、適用が必要
- 「The update is already installed」を表示：修正パッケージは適用済み
このポイントだけ押さえておけば、都度サイトを見に行かなくてもUbuntuマシンから直接脆弱性の対応状況を確認できます。
OVALデータで網羅的に確認する
特定のCVEの対応状況だけを確認したいのであればpro fixコマンドは便利です。
しかしながら実際は複数の脆弱性の対応状況を調べなくてはなりません。Ubuntu向けに公開されている脆弱性情報を元に、システムにインストールされたパッケージを網羅的に調べたいなら「OpenSCAP + Ubuntu OVAL」を使うといいでしょう。
OpenSCAPは、システムのセキュリティ状態を検査するためのツール群です。「SCAP（Security Content Automation Protocol）」という標準規格に対応しており、機械的にシステムを検査する仕組みが備わっています。たとえばパッケージの更新状況や、セキュリティに関する設定状況などを確認できます。
検査にあたってはシステムごとに適切なデータが必要です。たとえば同じ脆弱性でもRHELとUbuntuでは対象となるパッケージ名やバージョンが異なります。これらのデータを提供するための検査言語が「OVAL（Open Vulnerability and Assessment Language）」です。XML形式で、パッケージのバージョンや設定値などの検査条件を定義します。他にもRed HatやDebianなど、サーバー用途で使われることも多いメジャーなディストリビューションの多くが、個々のOVALデータを提供しています。
これはUbuntuも例外ではありません。Ubuntuではリリースごと（と特定の構成ごと）に、3種類のOVALデータを提供しています。
- CVE番号に紐付いた脆弱性定義（CVE）：当該脆弱性の影響を受けると判断されると「true」となる条件定義
- USN番号に紐づいたパッチ定義（USN）：当該脆弱性のパッチが適用されていないと判断されると「true」になる条件定義
- パッケージに紐付いた脆弱性定義（PKG）：当該パッケージがなんらかの脆弱性の影響を受けると判断されると「true」になる条件定義
脆弱性定義とパッチ定義はOVALの文脈において「classの値」で定義されています。Ubuntuの場合、CVE番号がUbuntuに影響すると判断された場合、CVE OVALが更新されます。しかしこの時点では対応パッケージは提供されているとは限らず、USN OVALが更新されていない可能性もあります。つまりCVE OVALでは「脆弱性の影響あり」と判断されても、USN OVALでは「脆弱性対応のために更新が必要なパッケージはなし」となる可能性があります。これらはそれぞれ確認する用途が異なる点に注意してください。
- 公開されているCVE番号についてUbuntuシステムに影響するか確認したい場合はCVE OVALを使う
- 現在のシステムで未更新のパッケージとそれに紐付いたCVE番号がないかを確認したい場合はUSN OVALを使う
大まかには上記の使い分けになります。PKG OVALについては、PKG単位で結果を得たい場合のみ使います。
実際に使い方を確認しましょう。まずはOVALデータをパースするためのOpenSCAPツールをインストールします。
$ sudo apt -U install openscap-scanner $ oscap --version OpenSCAP command line tool (oscap) 1.4.3 Copyright 2009--2023 Red Hat Inc., Durham, North Carolina. ==== Supported specifications ==== SCAP Version: 1.3 XCCDF Version: 1.2 OVAL Version: 5.11.3 CPE Version: 2.3 Asset Identification Version: 1.1 Asset Reporting Format Version: 1.1 ==== Capabilities added by auto-loaded plugins ==== SCE Version: 1.0 (from libopenscap_sce.so.33) （後略）
次にCVE OVALとUSN OVALをそれぞれダウンロードしましょう。
$ wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).cve.oval.xml.bz2 $ wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2 $ bunzip2 com.ubuntu.$(lsb_release -cs).cve.oval.xml.bz2 $ bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
これらのファイルは定期的に更新されますので、常に最新のものをダウンロードするようにしてください。
次にOVALファイルを使って、システム内部を検証します。
$ oscap oval eval --report report-cve.html com.ubuntu.$(lsb_release -cs).cve.oval.xml Definition oval:com.ubuntu.resolute:def:2026999990000000: true Definition oval:com.ubuntu.resolute:def:202699980000000: false Definition oval:com.ubuntu.resolute:def:202699830000000: false Definition oval:com.ubuntu.resolute:def:202699810000000: false Definition oval:com.ubuntu.resolute:def:202699230000000: false Definition oval:com.ubuntu.resolute:def:2026992160000000: true Definition oval:com.ubuntu.resolute:def:2026992150000000: true
このコマンドは静的なHTMLファイルかXMLファイルしか生成できません。適当なブラウザーで内容を確認しましょう。
CVE OVALは「Ubuntuシステムに影響するすべてのCVE番号」を確認することになります。そのリリースにおける脆弱性への対応が不明な項目も確認対象となるため、Resultが「true」になる項目、つまり脆弱性に対応できていないとされる項目は多岐に渡ります。日々脆弱性が見つかる状況で、これがオールグリーンになることはまずないと考えたほうが良いでしょう。
それより確認すべきはUSN OVALのほうです。こちらは脆弱性対応バージョンが提供済みパッケージのみを対象としているため、原則としてオールグリーンになることが理想です。ただしUbuntu Proで提供される「ESM（Extended Security Maintenance）」対象のパッケージもリストアップされます。ESM無効化環境では、オールグリーンとならない可能性もあります。
たとえばUSN OVALの画像で唯一赤くなっているUSN-8401-1はESMのみで修正されています。pro fixを使ってもそのように通知されるのです。
$ pro fix --dry-run USN-8401-1
WARNING: The option --dry-run is being used.
No packages will be installed when running this command.
USN-8401-1: Netty vulnerabilities
Associated CVEs:
- https://ubuntu.com/security/CVE-2026-42586
- https://ubuntu.com/security/CVE-2026-42579
- https://ubuntu.com/security/CVE-2026-42585
- https://ubuntu.com/security/CVE-2026-42581
- https://ubuntu.com/security/CVE-2026-42584
- https://ubuntu.com/security/CVE-2026-42578
Fixing requested USN-8401-1
1 affected source package is installed: netty
(1/1) netty:
A fix is available in Ubuntu Pro: ESM Apps.
The machine is not attached to an Ubuntu Pro subscription.
To proceed with the fix, a prompt would ask to attach
the machine to a subscription or use an existing token.
{ pro attach }
Ubuntu Pro service: esm-apps is not enabled.
To proceed with the fix, a prompt would ask permission to automatically enable
this service.
{ pro enable esm-apps }
{
apt update && apt install --only-upgrade -y libnetty-buffer-java libnetty- \
common-java libnetty-java
}
✔ USN-8401-1 is resolved.
このようにUbuntuのOVALデータを使うと、Ubuntuの流儀に従った脆弱性の対応状況を確認できます。ただし生成されるファイルがXMLかHTMLのみであり、severityでのフィルタリング等にも対応していません。そのためこれだけでは使いまわしづらい部分も多々あります。しかしながら今ならXMLからデイリーでレポートを生成することもAIにお任せすれば一瞬で作ってくれますし、うまく活用すると便利でしょう。
TrivyやGrypeも活用する
これまで紹介したproコマンドや、Ubuntu OVALデータを活用する方法は、Ubuntuにのみ適用可能な方法です。それに対して現在ではよりシステムに依存しないツールもたくさん存在します。たとえば、TrivyやGrypeのようなコンテナイメージのセキュリティ監視ツールは、コンテナだけでなくホストOSに対しても実行できます。
これらのツールの利点は、OSに依存せず検査してくれる点です。proやUbuntu OVALはあくまでUbuntuからaptコマンドでインストールしたソフトウェアが対象となります。つまりpipやnpm、cargoでインストールされたソフトウェアは対象外です。それに対してTrivyやGrypeはapt以外の方法でインストールしたソフトウェアも検査対象にできます。よってこれらのツールを併用することも検討すると良いでしょう。
ただし「ホストOSはできるだけ薄くし、pip等でインストールするサードパーティソフトウェアはコンテナに入れる」ほうがおすすめです。ホストOSは、aptからインストールできる基本的なツール類に限定し、これはproコマンドやUbuntu OVALデータで検証します。これらでケアできないツールはコンテナの中にのみインストールし、Trivyなどのツールで検証するのです。これによりホストOSに余計なソフトウェアが入らなくなり、何かあったときの対応や別システムへの移行が楽になります。
CVE-2026-98432はなぜ対応が遅れたのか
ところで現在、直近で見つかったいくつかのLinuxカーネルの脆弱性、特にCVE-2026-98432が話題になっています。
この脆弱性はIPv4 TCP通信における、IPv4オプションの取扱方法に起因する問題です。公開後にAnthropicがroot権限取得可能である旨を報告した結果として、一気に危険度があがり、対応に追われました。
- 10月5日：Linuxカーネルに修正が取り込まれる（コミットの例）
- 10月15日：CVE-2026-98432が公開される
- 10月16日：Debian 13向けの修正版カーネル公開
- 10月24日：深刻度の評価が引き上げられ、緊急度が高くなる
- 10月27日：Anthropicが脆弱性を利用してリモートから管理者権限を取得できる旨を公開
- 10月29日：SUSEがSLES 16.0向けの修正版カーネル公開
- 11月1日：Red HatがRHEL向けの修正版カーネル公開
それに対してUbuntuは11月2日時点でも「準備中」というステータスです。より厳密に言うと、10月22日ごろにはパッケージの準備を開始し、10月28日にはproposedに入り、11月3日にはテストを求めているアナウンスが流れる状態でした。つまりまったく動いていなかったわけではなく、動作確認に時間がかかっていたと表現するほうが正しいでしょう。
実はこの流れには前振りがあります。それがUbuntu Weekly Topicsの10月2日号に掲載された、「カーネルの更新ポリシーの周期変更」です。カーネルはUbuntuの中でも比較的高頻度で更新されているパッケージではあったのですが、昨今の脆弱性の発見状況を踏まえリリースサイクルを変えることになりました。
リリースの準備フェーズ1週間とテストフェーズ1週間の、計2週間でカーネルパッケージを準備します。ただしテストフェーズと次の準備フェーズをオーバーラップさせることで、「毎週カーネルをリリースする」ことを目指すのです。これにより新規の脆弱性もできるだけ短い周期での対応を目指していました。
問題はこの開発サイクルが9月末に始まったばかりであるということ。まだ開発サイクルがこなれておらず、スケジュール通りに進むとは限りません。そこで9月28日からと、10月12日からは「オーバーラップしない」形の2週間の開発サイクルにチャレンジし、10月26日からはオーバーラップする予定でした。つまりちょうど諸々準備して入れ替える時期ではあったのです。
10月12日のサイクルでは、CVE-2026-98432の修正を取り込めるかどうか微妙な時期でした。おそらくその結果として、10月26日のサイクルへと入ることになってしまいます。ただ状況を鑑みて少し前倒しで準備フェーズを始めて、10月28日にテストフェーズへと入ったというのが実情のようです。当初の予定通りに進めば、11月9日ごろには正式にリリースされるでしょう[4]。一言で言うと「間が悪すぎた」となります。
UbuntuではUbuntu Proにより最長15年間サポートするため、現在は14.04以降の8リリース分のカーネルをメンテナンスしています。1リリースごとに各種クラウドサービス向けのカーネルもあるため、その数は膨大です。そこでカーネルに関しては各種テストを自動化しつつ、「Kernel Team Dashboard」で開発・テスト状況を確認できるようにしています。
今後は新しい開発サイクルがうまく回れば、通常のカーネルだけでなく他の特殊カーネルも含めて、より短い周期で脆弱性対応が行えるはずです。
來源：gihyo.jp · gihyo.jp