Linux カーネル脆弱性 3 件｜KEV 掲載後の影響判定と完了確認

はじめに

2026 年 9 月 18 日、米 CISA は Linux カーネルの脆弱性 CVE-2025-39682、CVE-2026-53266、CVE-2025-39964 の 3 件を KEV（Known Exploited Vulnerabilities）カタログに追加しました。3 件とも実環境での悪用を理由に掲載されたものですが、影響を受ける機能と攻撃の前提は 3 件で大きく異なります。

Linux サーバー、仮想マシン、クラウド上のインスタンス、コンテナホストを管理する立場では、自社のカーネルが対象か、過去の定期更新ですでに修正されていないか、パッケージを更新すれば対応完了と言えるのかを短時間で判断する必要があります。ところが、同じ Ubuntu 22.04 LTS でも、使っているカーネルパッケージによって 3 件の判定結果が変わります。OS 名や上流カーネルのバージョン番号だけでは判定できない点が、今回の 3 件で特に注意したいところです。

結論として、影響判定の単位は OS 名ではなく、稼働中のカーネルパッケージです。配布元の CVE ページで自環境のパッケージ（標準カーネル、HWE、クラウド向けなど）の状態を確認し、修正版があれば更新と再起動を行い、修正済みカーネルが稼働していることを確かめた時点で対応完了と判断します。2026 年 9 月 24 日時点では、Ubuntu 22.04 LTS／24.04 LTS の標準カーネルに CVE-2026-53266 の修正版がまだ提供されていないため、この 1 件は設定の確認と修正版の待機を並行させることになります。

CVE-2025-39682・CVE-2026-53266・CVE-2025-39964 の違いと KEV 掲載の要点

3 件は KEV 追加日が同じでも、脆弱性の初公開時期、対象機能、攻撃の前提が異なります。まず日付と期限を出典ごとに分け、次に 3 件の違いを整理します。

公開日・KEV 追加日・期限を出典ごとに分ける

解説記事や集約サービスでは、CVE の公開日、KEV 追加日、記事の公開日が混在しやすいため、事実ごとに出典を分けて整理します。KEV の値は、CISA が GitHub で公開している KEV データ（cisagov/kev-data、カタログ版 2026.09.23）で確認しました。

CVE-2025-39682 と CVE-2025-39964 は、KEV 追加の約 1 年前に公開された脆弱性です。配布元の修正版はすでに出ており、定期更新で修正済みカーネルへ入れ替わっている環境もあります。一方、CVE-2026-53266 は 2026 年 6 月の公開で、修正版の提供状況が配布元やパッケージごとに分かれています。

KEV データの期限欄は、3 件とも 9 月 21 日という 1 つの日付です。資産が外部公開されているかどうかによる区分は期限欄には表れず、対応内容（requiredAction）の中で、各組織が資産の公開状況を評価するよう求めています。

参考: CISA Known Exploited Vulnerabilities Catalog
“Stakeholders are responsible for evaluating each asset’s internet exposure”
（関係者は、各資産のインターネットへの露出状況を評価する責任を負う）
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Qualys は、BOD 26-04 のもとで CVE-2025-39682 は全資産が 3 日、残る 2 件は外部公開資産が 3 日・内部資産が 14 日の対象になると説明しています。この区分は Qualys の説明であり、本記事の執筆時点では CISA の BOD 26-04 本文と実装ガイダンスのページを直接確認できていません。

参考: Qualys
“a 3-day window applies to CVE-2025-39682 across all assets”
（CVE-2025-39682 には、すべての資産で 3 日の期間が適用される）
https://blog.qualys.com/product-tech/2026/09/23/cisa-bod-26-04-timelines-for-three-linux-kernel-cves

公式データで確認できるのは、CVE Record の CISA-ADP コンテナにある SSVC の値です。3 件とも Exploitation は active、Technical Impact は total で、Automatable は CVE-2025-39682 のみ yes、残る 2 件は no です。Qualys の説明は、この Automatable の違いと、BOD 26-04 の期限区分の組み合わせに矛盾しない内容です（編集部の照合であり、CISA の公式本文による確認ではありません）。期限区分の読み方は、既存記事『BOD 26-04 とは｜KEV と外部公開で決まる対応期限の読み方』で整理しています。

BOD 26-04 の期限は米国の連邦民間行政機関に対する要求であり、日本の一般企業に義務として適用されるものではありません。また、KEV 掲載は悪用が確認されたことを示すもので、すべての環境で攻撃が成立することや、自社で侵害が起きたことを意味するものではありません。自社の優先度付けの参考として扱うことをおすすめします。

3 件の対象機能と攻撃前提の比較

3 件の違いを、対象機能、公式に確認できる攻撃前提、想定される影響、自環境で照合する情報の 4 点で比較します。攻撃前提と影響は、評価主体ごとに表現が異なるため出典を付記しています。

3 件を一律に「認証不要のリモートコード実行」や「root 権限の取得」として扱うのは適切ではありません。ネットワーク越しに到達し得るのは kTLS を使う CVE-2025-39682 で、残る 2 件はローカルでの実行が前提です。以下、判定に影響する点を CVE ごとに補足します。

CVE-2025-39682｜kTLS 受信処理の長さ 0 レコード

kTLS（カーネル TLS）は、TLS レコードの暗号化・復号をカーネル内で処理する機能です。本脆弱性は受信処理（net/tls/tls_sw.c）で長さ 0 のレコードを扱う際の不備です。Linux Kernel CNA は CVSS の評価理由の中で、kTLS を有効にした TCP ソケットに対して通信相手が細工したレコードを送ることで到達できるとし、影響を受け得る利用例として kTLS を使う OpenSSL、NFS over TLS などを挙げています。

参考: Red Hat（CVE-2025-39682）
“remotely triggered only when kernel TLS (CONFIG_TLS with the TLS ULP) is in use”
（カーネル TLS（CONFIG_TLS と TLS ULP）が使用されている場合にのみリモートから発生させられる）
https://access.redhat.com/security/cve/CVE-2025-39682

TLS 通信を行っていることだけでは該当の根拠にならず、TLS の処理をカーネルに委ねる kTLS を使っているかどうかが優先度を分けます。なお、CNA の記録では脆弱なコードは上流 6.0 で入ったとされており、5.x 系を基にしたカーネルでは配布元が非該当と判定している例があります（次章で具体例を示します）。

CVE-2026-53266｜ebtables SNAT の ARP 書き換え

ebtables は、ブリッジを通過する Ethernet フレームにルールを適用する仕組みです。本脆弱性は、SNAT ターゲットのオプションである ARP の送信元ハードウェアアドレスの書き換え処理（--snat-arp）で、書き込み先の確認が不足していた問題です。ARP ヘッダーの送信元ハードウェアアドレスの役割は『ARP とは｜IP アドレスと MAC アドレスを結ぶ仕組みとルーター越えの違い』で解説しています。

参考: Red Hat（CVE-2026-53266）
“requires specific bridge netfilter rules to be configured”
（特定のブリッジ netfilter ルールが設定されている必要がある）
https://access.redhat.com/security/cve/CVE-2026-53266

一方、Linux Kernel CNA は CVSS の評価理由で、ebtables ルールの操作に必要な CAP_NET_ADMIN は、ユーザー名前空間とネットワーク名前空間を使えば名前空間内の権限で得られる場合があるとしています。Red Hat は既存のルール構成を前提に影響を限定し、CNA は攻撃者が名前空間内で条件を整える場合を想定しており、ホスト側に該当ルールがないことだけで非該当と断定しないことをおすすめします。

CVE-2025-39964｜AF_ALG ソケットの競合状態

AF_ALG は、ユーザー空間のプログラムからカーネルの暗号 API を利用するためのソケットです。本脆弱性は、同じソケットへの同時書き込みで内部状態が不整合になる競合状態（レースコンディション）です。CNA の記録では、上流 2.6.38 から影響を受けるとされており、対象となるカーネルの範囲が 3 件の中で最も広くなっています。

参考: CVE Record（CVE-2025-39964）
“any unprivileged local user — including one inside a container”
（コンテナ内を含む、任意の非特権ローカルユーザー）
https://www.cve.org/CVERecord?id=CVE-2025-39964

CNA は、必要なモジュールが要求に応じて自動で読み込まれることにも触れています。複数の利用者がログインするサーバー、CI の実行ホスト、コンテナホストのように、第三者のコードがローカルで動く可能性のあるホストほど優先度が高くなります。Red Hat は、この脆弱性について同社の基準を満たす緩和策はないとしており、対処は修正済みカーネルへの更新が中心になります。

CVSS は評価主体によって異なる

3 件の CVSS は、評価主体によって値とベクトルが異なります。CVSS を並べ替えの指標に使う場合は、どの主体の値かを明記して扱うことをおすすめします。

CVE-2026-53266 では、CNA が AV:L（ローカル）、Red Hat が AV:N（ネットワーク）と攻撃元区分の評価が分かれています。本記事の攻撃前提は、各主体が公開している説明文に基づいて整理しています。

Linux カーネルの影響判定｜Ubuntu と RHEL で照合する方法

影響判定は、稼働中カーネルのパッケージを特定し、配布元の CVE ページの該当行と照合する作業です。上流カーネルのバージョン番号との比較だけでは結論を出せません。コマンドによる確認手順は次章にまとめ、本章では判定の考え方と具体例を示します。

上流バージョンの比較だけでは判定できない理由

CVE Record には、上流の安定版ブランチごとの修正版が記載されています。たとえば CVE-2025-39682 では 6.1.149、6.6.103、6.12.44、6.16.4 などが修正版です。しかし、ディストリビューションのカーネルは上流のバージョン番号を維持したまま、修正を個別に取り込む（バックポートする）ため、上流の表と直接比較すると判定を誤ります。

• 見落とし: 上流の修正対象ブランチに 6.8 は含まれませんが、Ubuntu 24.04 LTS の 6.8 系カーネルには 6.8.0-86.87 で修正版が提供されています。上流の表だけでは「修正版がない」と誤読します。
• 過小評価: CVE-2026-53266 は、原因となった変更が 5.4 系などの古いブランチにも取り込まれていたため、CNA の記録では 5.4.73 以降の 5.4 系なども影響範囲に含まれています。

RHEL も同様で、RHEL 9 のカーネルは 5.14 系のバージョン番号のまま修正を取り込んでいます。判定には、上流の番号ではなく配布元が公開する CVE ごとの状態と修正版を使います。

Ubuntu は OS 名ではなくカーネルパッケージの行で判定する

Ubuntu の CVE ページは、リリースとソースパッケージの組み合わせごとに状態を表示します。同じ 22.04 LTS でも、標準カーネル（linux）、HWE カーネル（linux-hwe-6.8 など）、クラウド向けカーネル（linux-aws、linux-azure など）は別の行として扱われます。代表的な組み合わせを抜き出すと次のとおりです。

出典: Ubuntu の各 CVE ページ（最終更新 2026 年 9 月 22 日、9 月 24 日に確認）。表中の「影響なし」は Not affected、「修正待ち」は Vulnerable, work in progress、「影響あり（修正版なし）」は Vulnerable の表示です。

CVE-2025-39682 では、22.04 LTS の標準カーネル（5.15 系）は影響なしですが、同じ 22.04 LTS の linux-hwe-6.8 は影響を受け、修正版が提供されています。標準カーネルの判定結果を、HWE やクラウド向けカーネルに流用しないことが要点です。また、CVE-2025-39964 は 22.04 LTS の標準カーネルでは修正済みですが、linux-azure-fde の行は影響ありのままです。同じクラウド向けでも、パッケージごとに状態を確認する必要があります。

CVE-2026-53266 は、22.04 LTS／24.04 LTS の標準カーネルと主要なクラウド向けカーネルで修正待ちです。24.04 LTS では linux-hwe-7.0 に修正版（7.0.0-31.31~24.04.1）の記載がありますが、カーネル系列の変更はドライバーや周辺ソフトウェアの動作確認を伴うため、修正版の提供を待つ場合との比較で判断することをおすすめします。20.04 LTS は、CVE-2025-39964 の修正版が Ubuntu Pro 経由での提供です。

RHEL と派生ディストリビューションの確認

Red Hat の CVE ページでは、説明、Red Hat としての評価、緩和策に加え、製品ごとの影響状況と発行済みのセキュリティアドバイザリ（RHSA）が示されます。RHEL では、通常のストリームと EUS などの延長サポートで別のアドバイザリが発行されることがあるため、自環境のサブスクリプションと一致する製品の行を確認します。

本記事では、Red Hat の製品別の修正版番号を掲載していません。執筆時点で製品別の一覧を公式ページ上で確認しきれなかったためです。自環境の修正状況は、Red Hat の CVE ページと、ホスト上の dnf updateinfo の結果で確認することをおすすめします。

AlmaLinux、Rocky Linux、Oracle Linux などの RHEL 互換ディストリビューションは、それぞれのアドバイザリを独自のタイミングで公開します。Oracle Linux の UEK のように、カーネル自体が RHEL と異なる場合もあります。RHEL の修正状況を派生ディストリビューションへそのまま当てはめず、利用しているディストリビューションの公式情報で確認することをおすすめします。

機能の使用状況は優先度付けに使い、非該当の根拠にしない

3 件の対象機能がホストで使われているかは、更新の優先度を決める材料になります。次のコマンドは、いずれも設定を変更しない読み取り中心の確認です。

lsmod | grep -E '^(tls|ebt_snat|af_alg|algif_)'

grep -E 'CONFIG_(TLS|BRIDGE_EBT_SNAT|CRYPTO_USER_API)' /boot/config-$(uname -r)

1 つ目は、現在読み込まれているモジュールの確認です。2 つ目は、稼働中カーネルのビルド設定の確認で、出力の値を次のように読みます。

モジュールが読み込まれていないことは、その時点で使われていないことを示すにとどまり、非該当の根拠にはなりません。CVE-2026-53266 については、ホスト上の ebtables の nat テーブルに、--snat-arp を伴う snat ルールがあるかを確認します（root 権限で実行します）。

sudo ebtables -t nat -L

出力の各ルールで、-j snat と --snat-arp の組み合わせがあるかを見ます。ただし前述のとおり、CNA は名前空間内で攻撃者が条件を整える場合を想定しているため、この確認で該当ルールがなくても修正版の適用は計画することをおすすめします。

コンテナホストとクラウド上の Linux

コンテナはホストのカーネルを共有して動作します。コンテナイメージを更新しても、ホストのカーネルは修正されません。コンテナ内で uname -r を実行するとホストのカーネルのバージョンが表示されるため、対応はホスト（Kubernetes ではワーカーノード）のカーネル更新として計画します。CVE-2025-39964 の CNA がコンテナ内の非特権ユーザーを攻撃者として想定している点からも、コンテナホストは優先度の高い対象です。

クラウド上の Ubuntu では、前掲の表のとおり linux-aws、linux-azure などのクラウド向けパッケージごとに修正版の番号が異なります。マネージド Kubernetes のノードイメージなど、カーネルをクラウド事業者が提供する環境では、事業者のセキュリティ情報とノードイメージの更新方法を確認します。

更新から対応完了までの確認手順

対応完了は、修正済みパッケージがインストールされた状態ではなく、修正済みカーネルで稼働している状態で判断します。次の手順は Ubuntu と RHEL を例にしています。コマンドは Ubuntu Pro Client と Red Hat の公式ドキュメントで確認したものです。

cat /etc/os-release
uname -r

dpkg -s linux-image-$(uname -r) | grep -E '^(Version|Source):'

rpm -q kernel-core

pro fix --dry-run CVE-2025-39682
pro fix --dry-run CVE-2026-53266
pro fix --dry-run CVE-2025-39964

dnf updateinfo list updates security
dnf updateinfo info RHSA-YYYY:NNNN

sudo pro fix CVE-2025-39964

sudo dnf update --advisory=RHSA-YYYY:NNNN
sudo grubby --default-kernel

uname -r
pro fix --dry-run CVE-2025-39964

dnf updateinfo list security --installed

systemctl --failed

インストール済み・稼働中・ライブパッチ適用の違い

対応状況を報告する際は、次の 3 つの状態を区別して記録することをおすすめします。

修正済みパッケージをインストールした状態

ディスク上に新しいカーネルがあるだけの状態です。再起動するまでは、脆弱な旧カーネルが動作し続けます。

修正済みカーネルが稼働している状態

uname -r と稼働中パッケージのバージョンが、配布元の修正版以上である状態です。本記事ではこの状態を対応完了の基準としています。

ライブパッチで修正を適用した状態

稼働中カーネルに修正を反映した状態です。対象の CVE がパッチに含まれ、適用済みと表示される場合に限り、その CVE について稼働中カーネルへ反映されたと判断できます。

Livepatch と kpatch を使う場合の条件

Ubuntu の Canonical Livepatch や RHEL の kpatch を使うと、再起動を待たずに一部の修正を稼働中カーネルへ反映できます。ただし、サービスを有効にしていることだけで 3 件すべてが修正されたとは扱えません。対象の CVE、稼働中カーネルがライブパッチの対象であるか、パッチの適用状態を確認します。

sudo canonical-livepatch status --verbose

sudo kpatch list

Livepatch では、verbose 出力で対象 CVE の記載とパッチの適用状態を確認します。Canonical の資料では、パッチの適用期限（cut-off date）の設定によって最新のパッチが適用されない場合があり、その際は verbose 出力に警告が表示されると説明されています。対象 CVE の記載がない場合は、修正済みカーネルへの更新と再起動で対応します。

修正版がない場合の緩和策と注意点

Red Hat は CVE ごとに緩和策を示していますが、その対象条件と影響は CVE によって異なります。全環境に共通の設定変更として一律に適用せず、条件に当てはまる環境で影響を確認したうえで判断することをおすすめします。

CVE-2026-53266 の緩和策は既存ルールの書き換えを止めるものであり、CNA が想定する名前空間内での条件作りまで防げるかは、公式情報では確認できません。緩和策は修正版を適用するまでのつなぎとして扱い、修正版の提供状況を継続して確認することをおすすめします。モジュールの読み込みを止める手順は、Red Hat が案内するナレッジ記事（https://access.redhat.com/solutions/41278）を参照してください。

パッチ適用と侵害確認を分けて進める

パッチ適用は今後の悪用を防ぐための作業で、侵害確認はすでに悪用されていないかを確かめる作業です。目的が異なるため、担当、証跡、完了条件を分けて管理することをおすすめします。

KEV のフォレンジックトリアージ欄の読み方

KEV データでは、3 件とも forensicTriage が Yes です。Qualys も 3 件ともフォレンジックトリアージが必要と説明しています。BOD 26-04 では、フォレンジックトリアージを求める条件が資産の状況と組み合わせて定められており、その仕組みは既存記事で整理しています。

日本の一般企業が参考にする場合は、外部公開されているホスト、複数の利用者やコンテナが動くホスト、第三者のコードを実行する可能性があるホストから、パッチ適用とは別枠で侵害確認の要否を判断する進め方が考えられます（編集部の提案）。

公開 IoC が確認できない現状と確認の限界

2026 年 9 月 24 日時点で、KEV の記載、CVE Record、Ubuntu と Red Hat の CVE ページを確認した範囲では、3 件に固有の IoC（侵害指標）や専用の検知手順は公開されていません。KEV の備考欄に記載されているのは、上流の修正コミットへのリンクです。

そのため、ログや EDR の一般的な確認で不審な点が見つからなくても、この 3 件による侵害を否定する根拠にはなりません。一般的な確認は、兆候を見つけるための作業として位置づけます。手がかりの 1 つとして、CNA は CVE-2025-39682 と CVE-2025-39964 がカーネルの oops やパニックを引き起こし得ると評価しており、原因不明のカーネルエラーが記録されていないかを確認する方法があります。

journalctl -k --since "2026-09-01"

journald の永続保存が無効な環境では、再起動前のログは残りません。カーネルエラーの記録がないことも、侵害がなかったことを示すものではない点に注意が必要です。

不審な兆候がある場合の初動

原因不明のカーネルエラー、想定外のプロセスやアカウント、外部への不審な通信など、侵害を疑う兆候がある場合は、次の順で進めることをおすすめします。

1. 更新や再起動の前に、CSIRT や SOC など対応担当へ連絡する
2. メモリなどの揮発性情報とログの保全要否を、対応担当と判断する
3. ネットワークからの隔離は、証拠保全と業務影響を踏まえて判断する
4. 保全が済んだ後に、修正済みカーネルへの更新と再起動を行う

カーネルの更新には再起動が伴うため、不審な兆候がある場合は、再起動の前に保全の要否を決めておくことが重要です。兆候がない場合でも、確認した範囲、期間、使ったデータソースを記録しておくと、後から追加の IoC が公開された際に再調査の範囲を決めやすくなります。

まとめ

KEV に追加された Linux カーネルの 3 件は、kTLS、ebtables SNAT、AF_ALG と対象機能も攻撃の前提も異なります。影響判定は OS 名ではなく稼働中カーネルのパッケージ単位で行い、修正済みカーネルの稼働をもって対応完了と判断します。

• 3 件とも KEV 追加日は 9 月 18 日で、期限欄は 9 月 21 日
• 対象機能は kTLS 受信処理、ebtables SNAT、AF_ALG ソケット
• 影響判定は稼働中カーネルのパッケージ単位で行う。
• 上流バージョンの比較だけではバックポートされた修正を見落とす。
• Ubuntu LTS の標準カーネルは CVE-2026-53266 が修正待ち
• 対応完了は修正済みカーネルが稼働しているかで判断する。
• 公開 IoC がない現状では一般的な確認で侵害を否定できない。

以上、最後までお読みいただきありがとうございました。