トップ/記事一覧/Linuxカーネルの欠陥が悪用中、Red Hat 8と9は対象外 CVE-2026-53362
linux-kernel-cve-cover-ja

Linuxカーネルの欠陥が悪用中、Red Hat 8と9は対象外 CVE-2026-53362

LinuxカーネルのCVE-2026-53362が悪用確認済みとして米CISAのカタログに追加され、対応期限は2026年8月30日に設定されました。対象はカーネル6.0以降で、Red Hat Enterprise Linux 8・9とUbuntu 22.04以前は影響を受けません。修正版の一覧、ディストリビューション別の状況、バージョンの確認手順をまとめます。

ニュース2026年8月28日公開
目次
この記事のポイント

LinuxカーネルのCVE-2026-53362が悪用確認済みとして米CISAのカタログに追加され、対応期限は2026年8月30日に設定されました。対象はカーネル6.0以降で、Red Hat Enterprise Linux 8・9とUbuntu 22.04以前は影響を受けません。修正版の一覧、ディストリビューション別の状況、バージョンの確認手順をまとめます。

米国のサイバーセキュリティ機関CISAが2026年8月27日、Linuxカーネル(LinuxというOSの中核部分)の欠陥「CVE-2026-53362」を、実際の攻撃に使われた脆弱性のカタログに追加しました。米連邦政府機関に課された対応期限は2026年8月30日と、通常より短く設定されています。

サーバーにログインできる一般ユーザーが、管理者権限(root、システムを何でも操作できる最上位の権限)を奪える種類の欠陥です。ただし対象はカーネル6.0以降に限られ、5.x系のカーネルで動いている多くの業務サーバーは影響を受けません。Red Hat Enterprise Linux(RHEL)の8と9、Ubuntu 22.04・20.04も対象外です。

影響するのは、比較的新しいカーネルを載せた環境です。RHEL 10、Ubuntu 24.04以降、AlmaLinux 10、Debian 13、そして自前でビルドしたカーネルや、しばらく更新していないクラウド上の仮想マシンが該当します。

何が起きるのか

CVE-2026-53362: IPv6通信の処理でメモリを壊せる欠陥

カーネルのIPv6(新しい方のインターネット住所の規格)送信処理にある __ip6_append_data() という関数で、確保するメモリの大きさの計算を間違えていました。前のデータの断片を引き継ぐとき、その分の長さを足し忘れるため、本来の領域からはみ出して書き込みが起きます。

Red Hatの脆弱性情報では、社内の呼称として「kernel: ipv6 frag escape」と記録され、深刻度は4段階の上から2番目にあたる「Important」に分類されています。

引き金を引くのに特別な権限は要りません。UDPv6という通信を扱うソケット(プログラムが通信するときの出入口)を作り、MSG_MOREMSG_SPLICE_PAGES という2つの指定を組み合わせて送信するだけです。公開された説明文にも「権限のないユーザーが引き起こせる」と明記されています。壊れるのはカーネルが管理するメモリなので、そこから管理者権限の奪取につながります。

攻撃者がサーバーの前に座っている必要はありませんが、何らかの形でそのサーバー上でプログラムを動かせる状態は必要です。Webアプリの別の欠陥から取った低い権限のシェル、レンタルサーバーの自分の契約分、開発者用の踏み台サーバーのアカウントなど、一段下の足場があれば成立します。深刻度スコア(CVSS v3.1)は10点満点で7.8、攻撃元区分は「ローカル」です。

項目内容
識別番号CVE-2026-53362
深刻度7.8(CVSS v3.1)
Red Hat評価「Important」
攻撃元ローカル
(サーバー上で動かせる権限が必要)
必要な権限一般ユーザー
起きること管理者権限の奪取
悪用確認済み(2026年8月27日)

対象のカーネルと、直ったバージョンの一覧

原因となる計算ミスが入ったのはカーネル6.0です。したがって6.0より前のカーネルは影響を受けません。長期サポート版として広く使われている5.15系や5.10系、企業向けLinuxに載る4.18系・5.14系は、いずれも対象外です。

kernel.orgが配布する各系列のうち、修正が入ったのは次のバージョンです。

カーネルの系列影響するバージョン直ったバージョン
6.0より前影響なし
6.1系6.1.176 以前6.1.177
6.6系6.6.143 以前6.6.144
6.12系6.12.94 以前6.12.95
6.18系6.18.37 以前6.18.38
7.1系7.1.2 以前7.1.3
7.2系影響なし修正済みで公開

6.2系から6.11系のように、すでに上流での保守が終わっている系列には修正版が出ません。これらを使い続けている場合は、保守が続いている系列へ乗り換える必要があります。

Linuxディストリビューション別の対応状況

企業で使われることの多い配布版(ディストリビューション)ごとの状況です。2026年8月28日時点で各社が公開している情報にもとづきます。

配布版状態対応
RHEL 6 / 7 / 8 / 9影響なし対応不要
RHEL 10修正済みkernel-6.12.0-211.30.1.el10_2
(RHSA-2026:34911 / 7月2日)
RHEL 10.0 延長更新修正済みkernel-6.12.0-55.86.1.el10_0
(RHSA-2026:35840 / 7月6日)
Ubuntu 18.04 / 20.04 / 22.04影響なし対応不要
Ubuntu 24.04対象・修正待ち更新カーネルの配布を待つ
Ubuntu 25.10サポート終了扱いサポート中の版へ移行
Ubuntu 26.04対象・配布準備中7.0.0-31.31 で対応予定
自前ビルドのカーネル6.0以降なら対象上表の修正版へ入れ替え

Ubuntuのセキュリティ情報では、この欠陥の優先度は「high」に設定されています。24.04 LTSについては、8月28日時点でまだ修正カーネルが配布段階に達していません。CanonicalのCVE-2026-53362のページで最新の状態を確認してください。

Red Hatは再起動なしでカーネルに修正を当てる「kpatch」でも対応版(RHSA-2026:43826、7月22日)を出しています。止められない本番サーバーでは選択肢になります。

なお、RHEL 10と同じ系統のAlmaLinux 10・Rocky Linux 10も、上流と同じ6.12系カーネルを使っているため対象です。各プロジェクトの更新情報を確認してください。

使っているカーネルのバージョンを確認する

いま動いているカーネルの版は、次のコマンドで分かります。

uname -r

出てきた数字が 5. で始まっていれば対象外です。6. または 7. で始まっている場合は、先ほどの表と照らし合わせます。RHEL系では 6.12.0-211.30.1.el10_2 のように配布元独自の番号が付くため、上流の6.12.95という数字とは直接比較できません。パッケージの版で判断してください。

# RHEL / AlmaLinux / Rocky Linux
rpm -q kernel
dnf update kernel

# Ubuntu / Debian
dpkg -l | grep linux-image
apt update && apt upgrade

カーネルの更新は再起動して初めて反映されます。uname -r の結果が更新後の版に変わっているかどうかで、再起動が済んでいるかを判定できます。パッケージだけ新しくして再起動していないサーバーは、古いカーネルのまま動いています。

なぜ新しいカーネルだけが対象なのか

計算ミスそのものは、2022年秋に公開されたカーネル6.0で入りました。通信の送信処理を速くするために、データをコピーせず参照だけで受け渡す仕組みを入れた際の変更が発端です。ただし当時は、計算結果がマイナスになると処理側がエラーを返して止まっていたため、メモリの破壊までは進みませんでした。

その安全弁が外れたのが後の変更です。MSG_SPLICE_PAGES という指定を使った場合だけ、マイナスでも先へ進めるようになりました。これで、それまで止まっていた経路が最後まで走り、確保した領域の外側へ書き込むようになりました。修正パッチの説明文でも、この2つの変更の組み合わせで初めて成立した、と説明されています。

今回の修正は、はみ出した分の長さを確保サイズ側に足し、その分を後段から引くという単純な帳尻合わせです。あわせて、もう成立しないはずのマイナス値の例外処理も取り除かれました。動作を変える種類の変更ではないため、更新して挙動が変わることは想定されていません。

上流に修正が入ったのは2026年6月下旬から7月上旬にかけてで、Red Hatは7月2日に配布を始めています。CISAが悪用を確認してカタログに載せたのはその約2か月後、8月27日でした。修正が出てから悪用が確認されるまでに間があった形で、更新を回していた環境はこの間に済んでいることになります。

更新にともなう再起動をどう計画するか

カーネルの更新には再起動が要ります。ここが業務システムで一番引っかかる部分です。対象の切り分けが済んだあと、実際に再起動が必要な台数を数えてから計画を立てると、無駄な調整を減らせます。

冗長化されているサーバー群であれば、1台ずつ切り離して更新し、戻す順送りで止めずに済みます。冗長化していない単独のサーバーは、業務の止まる時間帯を押さえる必要があります。Red Hatのkpatchのように、稼働したままカーネルに修正を当てる仕組みを契約に含んでいる場合は、再起動を後ろ倒しにする判断もできます。

クラウド上の仮想マシンは、作ったまま長期間再起動していないものが残りやすい場所です。イメージから起動し直す運用なら、更新済みのイメージへ差し替えるだけで片付きます。逆に、長く動かし続けている踏み台や社内の自動実行サーバーは、手作業で拾う必要があります。

コンテナを使っている場合、カーネルはホスト側のものが使われます。コンテナのイメージをいくら新しくしてもこの欠陥は消えません。更新すべきはホストのカーネルです。マネージドのコンテナ基盤を使っているなら、事業者がホストのOSを保守しているかどうかを契約内容で確認してください。

攻撃されているのか

CISAは2026年8月27日、この欠陥を悪用が確認された脆弱性のカタログに収載しました。同カタログは、実際の攻撃で使われた証拠がある案件だけを載せる運用です。したがって悪用は確認済みです。連邦政府機関の対応期限は8月30日で、通常の3週間より大幅に短く切られています。

一方で、身代金要求型ウイルス(ランサムウェア)の攻撃活動で使われたかどうかは「不明」とされており、誰が何を狙って使ったかの具体的な情報は公開されていません。攻撃の手口や被害の規模を示す報告も、8月28日時点では確認できていません。

CISAのカタログに載っている案件はCISA KEV 日本語ダッシュボードで一覧できます。手元の製品が他にも載っていないか、あわせて確認しておくと無駄がありません。

何をすればいいか

最初にやるのは、対象かどうかの切り分けです。uname -r の結果が5.x系なら、この件での作業はありません。RHEL 8・9、Ubuntu 22.04以前で動いているサーバーも同様です。国内の業務システムはこの範囲に収まることが多く、実際に手を動かす必要がある台数は思ったより少ないはずです。

6.0以降のカーネルだった場合は、配布元の更新を当てて再起動します。RHEL 10とその派生は7月上旬に修正版が出ているので、通常の更新運用を回していれば済んでいる可能性が高いです。Ubuntu 24.04は修正カーネルの配布を待つ形になるため、Canonicalの情報を追ってください。

回避策として、IPv6を使っていない環境でIPv6自体を無効にする手はあります。ただしこれは設定変更の影響範囲が広く、名前解決やクラスタ通信が止まる例もあるため、更新までのつなぎとして限定的に判断すべきものです。

この欠陥は、サーバー上でプログラムを動かせる状態が前提です。裏返せば、一般ユーザーのログインを許していないサーバー、外部からコードを流し込まれる経路のないサーバーでは、単独で使われる余地が小さくなります。共用のレンタルサーバー、開発者が多数ログインする踏み台、コンテナを外部の利用者に開放している基盤といった環境から優先して片付けるのが現実的です。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go