4年前の Linux CVE-2022-0995 が KEV に入った - 自分のカーネルが該当するかを確かめる

CISA の KEV（Known Exploited Vulnerabilities）カタログに、2026年8月26日付で CVE-2022-0995 が追加された。Linux カーネルの watch_queue イベント通知サブシステムにある境界外書き込み（out-of-bounds write）で、NVD での公開は 2022年3月25日、アップストリームの修正コミットも同時期に入っている。是正期限は 2026年9月9日 である。

つまり、4年以上前に直っている欠陥が、いま悪用されているという話だ。この記事では、なぜそういうことが起きるのかと、自分の環境が該当するかを確かめる手順を扱う。攻撃手順は扱わない。

何が起きる欠陥なのか

NVD の記述はこうなっている。

An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system.

カーネルの状態の一部を上書きできるので、ローカルユーザーが特権を取るか、システムをサービス拒否に陥らせうる、という内容だ。報告者は Jann Horn。

CVSS は NVD の主評価で 3.1 の 7.8（High）、ベクタは次のとおり。

1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

読み方を分解しておく。

  • AV:L（Local） — ネットワーク越しには成立しない。そのマシン上で何かを実行できることが前提。
  • PR:L（Low） — 必要な権限は「一般ユーザー」。root は要らない。
  • UI:N — 被害者の操作は不要。
  • C:H / I:H / A:H — 機密性・完全性・可用性がすべて High。典型的なローカル権限昇格の形。

watch_queue は、カーネル内のイベント（キーリングの変更など）をユーザー空間へ通知するための仕組みで、比較的新しい機能だ。パイプをイベントの受け口として使う設計になっている。

なぜ4年前の欠陥が今なのか

3つの要因が重なっていると考えられる。

1つ目は、この種の欠陥が「単体では侵入経路にならない」ことだ。 AV:L・PR:L という条件は、成立させるには既にそのマシン上で一般ユーザーの権限を持っている必要があることを意味する。つまりローカル権限昇格は攻撃の連鎖の中間部品であり、初期侵入の統計には現れにくい。Web アプリの RCE で www-data を取り、そこから root へ上がるための道具として使われる。最初の穴ばかりが注目され、2段目は長く生き残る。

2つ目は、カーネル更新に再起動が要ることだ。 アプリケーションのパッチと違い、カーネルは入れ替えただけでは有効にならない。「再起動の調整がつかない」という理由で、パッケージだけ新しくて動いているカーネルは古い、という状態が普通に発生する。次の節の確認手順で、ここを見分ける。

3つ目は、機能の有無がビルド構成に依存することだ。 watch_queue はすべてのカーネルで有効になっているわけではない。有効なディストリと無効なディストリがあり、「Linux だから全部危ない」わけでも「新しいから安全」でもない。だから一律の判断ができず、環境ごとに確認する必要が出る。

自分の環境が該当するか

Ubuntu Security の CVE ページに、リリースごとの判定が出ている（2026年8月31日時点で確認）。

修正済み（fixed）:

  • 22.04 LTS jammy — linux 5.15.0-138.148 / linux-aws 5.15.0-1082.89 / linux-azure 5.15.0-1087.96
  • 20.04 LTS focal — linux-aws-5.15 5.15.0-1082.8920.04.1 / linux-hwe-5.15 5.15.0-138.14820.04.1

該当せず（not affected）:

  • 26.04 LTS resolute / 25.10 questing / 25.04 plucky / 24.10 oracular / 24.04 LTS noble / 23.10 mantic / 23.04 lunar、および 18.04 LTS bionic / 16.04 LTS xenial / 14.04 LTS trusty の多くのパッケージ

この分布から読み取れることは1つで、問題は 5.15 系カーネルを使い続けている環境に集中しているということだ。24.04 LTS 以降は該当せず、古い LTS も多くが該当しない。挟まれた 5.15 系だけが残っている。

確認は3手で済む。

1
2
3
4
5
6
7
8
# 1) いま動いているカーネル（再起動していないと古いまま）
uname -r

# 2) インストール済みのカーネルパッケージ（新しいものが入っていても、1と違えば未適用）
dpkg -l | grep -E '^ii\s+linux-image'

# 3) 再起動が必要かどうか（Debian 系）
ls -l /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs

1 と 2 がずれていたら、それが「パッケージは当てたが有効になっていない」状態である。 KEV の期限を見るときに効くのは 2 ではなく 1 のほうだ。

Ubuntu なら、uname -r が次を満たしていれば修正版になる。

  • 汎用カーネル: 5.15.0-138 以降
  • AWS 向け（linux-aws）: 5.15.0-1082 以降
  • Azure 向け（linux-azure）: 5.15.0-1087 以降

Red Hat 系は、Red Hat Bugzilla の 2063786 と、それに紐づく RHSA を確認する。アップストリームの修正コミットは 93ce93587d36 である。

1
2
# Red Hat / CentOS Stream / Alma / Rocky
rpm -q --changelog kernel | grep -m1 CVE-2022-0995

--changelog に CVE 番号が出てくれば、そのパッケージには修正が入っている。ただしこれも「入っているパッケージ」の話なので、uname -r との突き合わせは同じように必要だ。

クラウド別に何が要るか

いずれもディストリのカーネル更新であって、クラウド事業者側の修正ではない。

環境 対応 注意
AWS EC2 linux-aws を 5.15.0-1082.89 以降へ更新して再起動 Auto Scaling を使っているなら、更新済み AMI へ入れ替えてローリング置換するほうが停止時間が短い
GCP Compute Engine ディストリのカーネル更新後に再起動。GKE はノードプールのアップグレード Container-Optimized OS は 5.15 系より新しい構成が多く該当しない可能性が高いが、実際のカーネル版で確認する
Azure VM linux-azure を 5.15.0-1087.96 以降へ更新して再起動。AKS はノードイメージのアップグレード AKS はノードイメージ更新で Pod の退避を伴う

マネージドサービス（Lambda / Fargate / Cloud Run / RDS など）は、ホストカーネルを利用者が管理しないため、この CVE の直接の対象ではない。 対象になるのは、自分でカーネルを持っている環境だけだ。

更新までのあいだに効くこと

根本対策はカーネル更新で、それ以外は補助でしかない。そのうえで、成立条件から逆算して効くことが2つある。

1つは、前段を断つことだ。 AV:L・PR:L なので、成立には既にそのマシン上で一般ユーザー権限を持っていることが要る。逆に言えば、次の「一般権限を取られる経路」を潰すことは、この CVE に対しても直接効く。

  • コンテナからホストへ抜け出す経路（特権コンテナ、ホストパスのマウント、docker.sock の露出）
  • 共有ホスト上の一般ユーザーアカウント（不要なシェルアカウントの棚卸し）
  • Web アプリケーションからのコマンド実行（アップロードディレクトリの実行権限、テンプレートインジェクション）

もう1つは、自ビルドのカーネルを使っている場合の構成確認だ。 watch_queue を有効にしていないカーネルであれば、そもそも到達できない。

1
2
# 有効になっているか（ディストリ提供のカーネルでは変更できないので、確認のみ）
grep -i watch_queue /boot/config-$(uname -r)

ディストリ提供のカーネルでは構成を選べないので、大半の環境ではこれは判断材料にしかならない。

この件から持ち帰るもの

実務的な教訓は、KEV は「新しい CVE のリスト」ではないということだ。載る条件は「悪用が現に確認されたこと」であって、公開時期ではない。今回のように4年前のものが載ることもあるし、2015年のもの（同じ 8月26日に CVE-2015-3246 と CVE-2015-5287 が追加されている）が載ることもある。

したがって、脆弱性の棚卸しを「直近N日に公開された CVE」で回している運用は、この種の追加を取りこぼす。KEV カタログの差分そのものを監視対象にするほうが確実だ。カタログは JSON で公開されている。

1
2
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[] | select(.dateAdded >= "2026-08-26") | [.cveID, .vendorProject, .product, .dueDate] | @tsv'

日次で取得して前日との差分を取れば、「4年前の CVE が今日追加された」という形の変化を、公開日ベースの監視では見えない位置で捉えられる。

なお当サイトの姉妹サイト CVE Watch では、この CVE を含む High / Critical および KEV 収載の脆弱性について、クラウド・OS ごとの対応を日本語で整理している。

出典（いずれも2026年8月31日時点で確認）

  • NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-0995（CVSS 3.1 = 7.8 / vulnStatus = Analyzed / 公開 2022-03-25）
  • CISA KEV カタログ（収載 2026-08-26 / 是正期限 2026-09-09）
  • Ubuntu Security: https://ubuntu.com/security/CVE-2022-0995（リリースごとの修正状況）
  • アップストリーム修正コミット 93ce93587d36（torvalds/linux）
  • Red Hat Bugzilla 2063786

バージョン番号と判定は更新される場合があるため、適用前に各ベンダの一次情報で最新をご確認ください。

クラウド・インフラ
#セキュリティ #CVE #Linux #カーネル #KEV
4年前の Linux CVE-2022-0995 が KEV に入った - 自分のカーネルが該当するかを確かめる
https://blog.hashito.biz/2026/08/31/linux-cve-2022-0995-watch-queue-kev-check/
著者
hashito
作成日
2026年8月31日
著作権