【調査記録】Linuxカーネル432件CVE報道を自社環境へ落とし込む―Oracle Linuxの16件を実機で仕分けた話

冒頭文

2026年7月、Linuxカーネルに関する432件のCVEが、二日間という短期間に公開されたことが報じられました。

「432件」という数字だけを見ると、自社のLinuxサーバーにも数百件の重大な脆弱性が一度に発生したように感じます。

しかし、CVEの件数と、自社環境で実際に悪用可能な脆弱性の件数は同じではありません。

Linuxカーネルには、CPUアーキテクチャ、ファイルシステム、ネットワーク、仮想化、デバイスドライバーなど、膨大な機能が含まれます。一台のサーバーが実際に利用するのは、その一部だけです。Linuxカーネル公式文書でも、多数のCVEが個々のシステムには該当しないこと、適用可能性は利用者側で判断する必要があることが説明されています。

そこで、kurutann.comの本番環境へ配信されたOracle Linuxのセキュリティアドバイザリを起点に、次の情報を照合しました。

• 実行中のカーネル系列
• CPUアーキテクチャ
• インストール済みパッケージ
• 起動中のサービス
• 有効になっている機能
• 修正パッケージの適用状況
• 更新後に実際に起動しているカーネル

調査対象となった3件のOracle Linuxアドバイザリには、合計16件のCVEが含まれていました。

実機構成と照合した結果、稼働中の環境で更新対象として扱ったものは2件でした。残り14件は、アーキテクチャの不一致、対象コンポーネントの未導入、または非稼働のカーネル系列という理由で、現在の実行環境には該当しませんでした。

結論・要点

今回の結論は次のとおりです。

重要な結論は、次の二つです。

432件のCVEが公開された
        ≠
自社サーバーに432件の脆弱性が存在する

一方で、次の判断も誤りです。

自社環境では多くが非該当だった
        ≠
カーネル更新を実施しなくてよい

個別のCVEが非該当でも、同じセキュリティ更新には別の修正が含まれている可能性があります。

この記事で分かること

この記事では、次の内容を解説します。

• 432件のCVE公開をどのように受け止めるべきか
• LinuxカーネルでCVE件数が多くなる理由
• 432件から自社対象を絞り込む実務手順
• Oracle LinuxのELSAを読み解く方法
• UEKとRHCKを区別する方法
• CPUアーキテクチャによる影響差
• 未導入パッケージを非該当と判断する方法
• 16件の分類結果
• カーネル更新後に必要な動作確認
• アラート疲れを防ぐ再発防止策

対象読者・前提環境

対象読者は次のとおりです。

• Linuxサーバーを運用している人
• Oracle Linuxを使用している人
• 脆弱性スキャナーの大量アラートに悩んでいる人
• CVE番号だけで対応優先度を判断している人
• DockerやKVMを使用している人
• 自社環境に関係するCVEだけを正確に判定したい人
• 脆弱性調査の証跡を残したい人

本記事の自社調査結果は、次の構成を前提としています。

• CPUアーキテクチャ：x86_64
• 実行中カーネル：UEK
• Sambaサーバー：未導入
• Oracle Linuxのセキュリティ更新を利用

公開記事では完全なパッケージ番号を省略しています。正確なコマンド出力とパッケージ情報は、内部の変更管理記録で管理します。

何が起きたのか

2026年7月、Linuxカーネルチームが二日間で432件のCVEを公開したことが報じられました。

ただし、432件すべてが次のような脆弱性という意味ではありません。

• インターネットから未認証で悪用できる
• 全Linuxサーバーに共通して存在する
• 公開直後から攻撃されている
• すべて緊急パッチが必要
• 同じ攻撃条件を持つ

Linuxカーネルは、サーバー、スマートフォン、組み込み機器、スーパーコンピューターなど、非常に多様な環境で使われています。

同じLinuxカーネルのソースツリーには、次のようなコードが共存します。

Linuxカーネル
├─ x86_64向け処理
├─ ARM64向け処理
├─ RISC-V向け処理
├─ ネットワーク
├─ KVM仮想化
├─ ファイルシステム
├─ GPU・音声・USB
├─ 無線LAN
└─ 多数のデバイスドライバー

自社サーバーが利用していないアーキテクチャやデバイスのCVEは、現在の実行経路には入りません。

なぜLinuxカーネルでは大量のCVEが公開されるのか

Linuxカーネルプロジェクトは、CNAとしてLinuxカーネルのCVE番号を割り当てています。

CNAの正式名称は、CVE Numbering Authorityです。

Linuxカーネル公式文書では、通常の安定版リリースの過程で、潜在的なセキュリティ問題を持つ修正を識別し、慎重な方針でCVEを割り当てると説明されています。悪用方法が明確でない場合でも、カーネルの特殊な立場を考慮して広く採番されるため、CVE件数が多くなります。

ただし、今回の432件が短期間に集中した具体的な原因は、公開資料だけでは確認できません。

次の二つは分けて考える必要があります。

LinuxカーネルのCVE件数が全体的に多い理由
        ↓
公式の広い採番方針で説明できる

今回432件が二日間へ集中した理由
        ↓
公開情報だけでは断定できない

今回の調査範囲

今回、432件を無条件に一件ずつ判定したわけではありません。

自社サーバーへ実際に配信されたOracle Linuxのセキュリティアドバイザリを入口にしました。

調査対象は次の3件です。

ELSA-2026-500004は、CVE-2026-31663、CVE-2026-46316、CVE-2026-53362の3件を修正するUEK更新です。

ELSA-2026-22963は、6件のSamba脆弱性を修正するCritical指定の更新です。

ELSA-2026-25191は、Oracle Linuxのkernelパッケージ、つまりRHCK向けのセキュリティ更新です。アドバイザリのRelated CVEs欄には7件が記載されています。

Oracleのカーネルアドバイザリには累積的な変更履歴が含まれることがあります。今回の件数集計では、説明欄に現れるすべてのCVE表記ではなく、Related CVEs欄を基準にしました。

16件の分類結果

1. 稼働中のUEKで更新対象として扱った2件

ELSA-2026-500004に含まれる3件のうち、x86_64の稼働環境で更新対象として扱ったのは次の2件です。

ここでいう「更新対象」は、必ずしも攻撃が成立していたという意味ではありません。

実行中のカーネル系列へ修正が提供されており、自社構成と関係するコードであるため、セキュリティ更新として適用・確認したという意味です。

2. ARM64固有のため非該当となった1件

CVE-2026-46316の脆弱な処理は、ARM64専用のKVMコードにあります。

自社サーバーはx86_64であるため、該当する実行経路がありません。

ただし、CVE-2026-46316が非該当でも、ELSA-2026-500004全体を省略してよいわけではありません。同じ更新に、x86_64でも確認が必要な別のCVEが含まれているためです。

3. Samba未導入のため非該当となった6件

ELSA-2026-22963には、次の6件が含まれます。

• CVE-2026-1933
• CVE-2026-2340
• CVE-2026-3012
• CVE-2026-40170
• CVE-2026-4408
• CVE-2026-4480

OracleはこのアドバイザリをCriticalとして公開しています。

しかし、自社サーバーではSambaサーバーパッケージと関連サービスを使用していません。

このため、Sambaサーバー機能を経由する攻撃経路は存在しないと判定しました。

「ポートが閉じている」だけではなく、次の条件を確認することが重要です。

対象パッケージが存在しない
        ＋
対象プロセスが動作していない
        ＋
対象設定が存在しない
        ＋
待受ポートが存在しない

4. RHCKが非稼働のため現在の実行環境では非該当となった7件

ELSA-2026-25191は、Oracle LinuxのRHCK向けkernelパッケージの更新です。Related CVEs欄には次の7件が記載されています。

• CVE-2026-31419
• CVE-2026-31467
• CVE-2026-31532
• CVE-2026-31581
• CVE-2026-43037
• CVE-2026-43501
• CVE-2026-46054

自社サーバーでは、RHCKではなくUEKが実行中です。

そのため、現在動作しているカーネルに対する直接の更新ではありません。

ただし、RHCKがディスク上にインストールされ、GRUBの代替起動先として残っている場合は注意が必要です。

将来、起動カーネルがRHCKへ切り替われば、判定結果も変わります。

したがって、正確なステータスは次です。

現在の実行環境では非該当。ただし、ブート設定変更時は再評価が必要。

調査の全体フロー

432件の大量CVE公開を把握
        │
        ▼
OSベンダーのアドバイザリを確認
        │
        ▼
自社リポジトリに配信された更新を抽出
        │
        ▼
Related CVEsを一覧化
        │
        ▼
┌─────────────────────────────┐
│ 実機情報と照合               │
├─────────────────────────────┤
│ CPUアーキテクチャ            │
│ 実行中カーネル系列           │
│ インストール済みパッケージ   │
│ 起動中サービス               │
│ 機能・設定                    │
│ ネットワーク到達性           │
└─────────────────────────────┘
        │
        ▼
affected / fixed / not affected /
under investigation に分類
        │
        ▼
更新・再起動・動作確認
        │
        ▼
証跡を保存

確認方法1：CPUアーキテクチャを確認する

目的

ARM64固有、x86_64固有などのCVEを判定します。

実行場所

調査対象のLinuxサーバーです。

コマンド

uname -m

x86_64の例

x86_64

ARM64の例

aarch64

判断方法

CVEの脆弱なコードがarch/arm64/配下にあり、実機がx86_64であれば、そのARM64固有処理は実行されません。

確認方法2：実行中のカーネル系列を確認する

目的

UEKとRHCKのどちらで現在起動しているか確認します。

コマンド

uname -r

UEKで一般的に見られる例です。

6.x.x-xxx.el10uek.x86_64

RHCKで一般的に見られる例です。

6.x.x-xxx.el10_2.x86_64

パッケージも確認します。

rpm -q kernel-uek kernel

判断方法

インストール済みパッケージだけではなく、uname -rで現在実行中のカーネルを確認します。

RHCKがインストールされていても、UEKで起動している間はRHCKのコードは動作していません。

確認方法3：アドバイザリの状態を確認する

コマンド

sudo dnf updateinfo info \
  --advisory ELSA-2026-500004

sudo dnf updateinfo info \
  --advisory ELSA-2026-25191

sudo dnf updateinfo info \
  --advisory ELSA-2026-22963

判断方法

環境によって表示形式は異なりますが、次を確認します。

• 更新可能なパッケージがあるか
• アドバイザリがインストール済みか
• 対象リポジトリが有効か
• 実行中カーネルが更新後のものか

確認方法4：Sambaの有無を確認する

パッケージ確認

rpm -qa |
  grep -Ei '^samba($|-)'

実行ファイル確認

command -v smbd
command -v samba-dcerpcd

プロセス確認

pgrep -a smbd
pgrep -a samba-dcerpcd

待受ポート確認

sudo ss -lntup |
  grep -Ei 'smbd|samba|dcerpc|:(135|139|445)\b'

非該当と判断できる例

• Sambaサーバーパッケージがない
• smbdとsamba-dcerpcdがない
• Sambaプロセスが動作していない
• 関連する待受ポートがない

クライアントライブラリだけが存在する場合は、サーバー側の攻撃経路があるかを別途確認します。

対処方法

セキュリティ更新を適用する

本番環境では、事前にスナップショットとバックアップを取得します。

更新可能なセキュリティパッケージを確認します。

sudo dnf updateinfo list --security

セキュリティ更新を適用します。

sudo dnf upgrade --security

特定のアドバイザリを指定する場合です。

sudo dnf upgrade \
  --advisory ELSA-2026-500004

注意事項

カーネル更新には再起動が必要です。

実行前に次を確認してください。

• VPSスナップショット
• データベースのバックアップ
• Dockerボリュームのバックアップ
• SSH以外の管理コンソール
• GRUBに旧カーネルが残っていること
• メンテナンス時間
• 主要サービスの停止・起動手順

更新後の動作確認

実行中カーネルを確認する

uname -r

新しいカーネルをインストールしただけでは不十分です。

再起動後にuname -rが修正版へ切り替わっていることを確認します。

失敗したサービスを確認する

sudo systemctl --failed

正常例です。

0 loaded units listed.

カーネルログを確認する

sudo journalctl -b -p warning

次を確認します。

• kernel panic
• モジュール読み込み失敗
• ファイルシステム異常
• ネットワーク異常
• SELinux拒否
• Docker起動失敗

コンテナを確認する

docker ps
docker compose ps

Webサイトを確認する

curl -I https://kurutann.com/

構成に応じて、想定した200、301、302などが返ることを確認します。

調査結果をVEX形式で管理する

大量のCVEを管理する場合、単なる「対応済み・未対応」だけでは不十分です。

次の状態を使うと整理しやすくなります。

今回の例です。

再発防止

資産台帳へ実行環境を記録する

最低限、次を管理します。

CVE判定に証拠を付ける

「非該当」とだけ記録せず、理由と確認結果を残します。

CVE：CVE-2026-46316
判定：not affected
理由：ARM64専用コード
証拠：uname -m = x86_64
確認日：YYYY-MM-DD
再評価条件：CPUアーキテクチャまたは基盤変更

非稼働パッケージも管理する

現在UEKで起動していても、RHCKが代替カーネルとして残っている場合があります。

• 不要なら削除を検討する
• 必要なら更新を継続する
• GRUBのデフォルト設定を監視する
• 再起動後に必ずuname -rを確認する

CVE件数だけで優先順位を決めない

優先順位は次の要素で決めます。

対象製品・パッケージ
        ↓
実行中か
        ↓
アーキテクチャ
        ↓
機能・設定
        ↓
攻撃者からの到達性
        ↓
必要な権限
        ↓
悪用状況
        ↓
修正状況

注意点・よくある誤解

432件すべてが自社に影響するのか

影響しません。

Linuxカーネル公式も、巨大なソースツリーのうち各システムが利用するのは一部であり、多くのCVEが個別環境には該当しないと説明しています。

非該当なら更新しなくてよいのか

個別CVEが非該当でも、同じパッケージ更新には別の修正が含まれます。

カーネルは個別パッチを選別するより、OSベンダーが提供する更新単位で適用することが基本です。

パッケージを更新すれば完了か

カーネルは再起動しなければ切り替わりません。

uname -rで実行中のカーネルを確認してください。

RHCKを使っていないから完全に無関係か

現在の実行環境では非該当です。

ただし、GRUB設定の変更や障害時のフォールバックでRHCKが起動すれば、判定をやり直す必要があります。

バージョンを公開しなければ安全か

公開情報を減らすことは補助的な運用方針です。

根本対策は、更新、再起動、設定管理、アクセス制御、監視です。

まとめ

2026年7月、Linuxカーネルに関する432件のCVEが二日間で公開されたことが報じられました。

しかし、CVE件数は、そのまま自社環境の脆弱性件数を表すものではありません。

今回の調査では、自社環境へ配信された3件のOracle Linuxセキュリティアドバイザリを確認し、Related CVEsに含まれる合計16件を実機構成と照合しました。

結果は次のとおりです。

稼働中UEKで更新対象     2件
ARM64固有で非該当       1件
Samba未導入で非該当     6件
RHCK非稼働で非該当      7件
────────────────────────
合計                    16件

重要なのは、CVE番号やCVSSだけを見て判断しないことです。

ベンダーアドバイザリ
        ＋
実行中パッケージ
        ＋
CPUアーキテクチャ
        ＋
有効な機能と設定
        ＋
攻撃経路
        ＋
修正後の動作確認

この照合によって、不要な緊急対応を減らし、本当に対応が必要な更新へ集中できます。

一方で、「自社に該当しないCVEが多かった」という理由で、OSベンダーのセキュリティ更新を省略してはいけません。

個別CVEの影響判定と、パッケージ更新の適用判断は、分けて管理する必要があります。

FAQ

432件をすべて一件ずつ読む必要がありますか

通常は、最初に利用中OSのベンダーアドバイザリへ絞り込みます。

その後、インストール済みパッケージ、アーキテクチャ、機能、設定と照合します。

Oracle LinuxではNVDだけを確認すればよいですか

NVDだけでは、Oracleが修正をバックポートしたパッケージ番号や更新単位を判断できない場合があります。

Oracle LinuxのCVE情報とELSAを優先して確認し、NVDやkernel.orgを技術的な補足に使用します。

UEKとRHCKの両方が入っている場合はどうしますか

uname -rで現在の実行中カーネルを確認します。

さらに、再起動時に別系列へ切り替わる可能性があるため、GRUBのデフォルト設定と代替カーネルの更新状態も管理します。

Sambaパッケージが一部だけ入っている場合はどうしますか

クライアントライブラリだけか、サーバープロセスも含まれるかを確認します。

smbd、samba-dcerpcd、有効設定、待受ポートを確認してください。

「not affected」は永久に有効ですか

構成が変われば判定も変わります。

アーキテクチャ変更、パッケージ追加、サービス有効化、起動カーネル変更を再評価条件として記録してください。

参考情報

• Linuxカーネル公式のCVE採番方針と、個別環境での適用可能性に関する説明。
• LinuxカーネルCVEが二日間で432件公開されたことに関する報道。
• Oracle Linux ELSA-2026-500004。
• Oracle Linux ELSA-2026-22963。
• Oracle Linux ELSA-2026-25191。

厳選解説記事シリーズ（全7本へのリンク）

今回の調査で判明した各CVEの技術的詳細・攻撃条件・影響度について、以下の8本の解説記事に分けて詳細にレポートしています。

一次情報・参考文献

• Oracle Linux Security Advisory: ELSA-2026-500004 (Unbreakable Enterprise Kernel)
• Oracle Linux Security Advisory: ELSA-2026-25191 (kernel)
• Oracle Linux Security Advisory: ELSA-2026-22963 (samba)
• NVD (National Vulnerability Database)