新しいカーネルほど当たる — Linux CVE-2026-53362

脆弱性対応でつい先に手が伸びるのは、古い環境である。長く上げていないサーバがいちばん危ない、というのは経験則としてだいたい正しい。だから資産台帳を新しい順に並べ替えて、下のほうから潰していく。

その反射が空振りする種類の脆弱性がある。修正が新しいコードにしか入っていない欠陥だ。原因となったコードそのものが比較的新しく、古い系列にはそもそも存在しない。この場合、上げている環境ほど該当し、放置している環境は無関係になる。

Linux カーネルの CVE-2026-53362 がそれにあたる。CISA が 2026年8月27日に KEV（悪用が確認された脆弱性カタログ）へ収載し、是正期限を 2026年8月30日に設定した。収載から3日である。

この記事では、なぜ古い環境が無関係になるのかを整理し、最後に自分のホストが該当するかを判定するシェルスクリプトを置く。

何が起きるのか

上流のコミットメッセージによれば、問題は net/ipv6/ip6_output.c の __ip6_append_data() にある。この関数には、確保の仕方が違う複数の経路がある。そのうちページ確保を伴う分岐（MSG_MORE 指定時、NETIF_F_SG 対応の NIC、あるいは fraglen が大きいとき）で、長さの計算が次のようになっていた。

alloclen = fragheaderlen + transhdrlen;
pagedlen = datalen - transhdrlen;

ここで datalen は、その手前で

datalen = length + fraggap;

として計算されている。fraggap は、直前のスキップバッファから引き継ぐ端数のことだ。つまり datalen にはすでに fraggap が入っている。ところが alloclen の式には fraggap が出てこない。確保した領域より、そこへ書き込む量のほうが多くなる。fraggap が 0 でない場合に、ヒープの領域外へ書き込みが起きる。

CISA の記載は「IPv6 ネットワークサブシステム経由で権限昇格を許す Linux カーネルの脆弱性」で、SUSE・Red Hat をはじめ Linux を用いる複数の製品に影響しうる、としている。

CVSS 3.1 は NVD・Red Hat とも 7.8 High（Red Hat の格付けは Important）、ベクタは CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H である。

古い環境が無関係になる

該当範囲を、ディストリビューションの判定そのままで並べる。

ディストリ	判定
RHEL 6 / 7 / 8 / 9	Not affected
RHEL 10	該当。RHSA-2026:34911（kernel-6.12.0-211.30.1.el10_2）
RHEL 10.0 EUS	該当。RHSA-2026:35840（kernel-6.12.0-55.86.1.el10_0）
Ubuntu trusty / xenial / bionic / focal / jammy	not-affected
Ubuntu noble	needed（提供待ち）
Ubuntu resolute	pending（7.0.0-31.31）
Debian bookworm	resolved（6.1.177-1、セキュリティ更新は 6.1.180-1）
Debian bullseye	resolved（urgency: unimportant）

上流で修正が入ったのは 7.2-rc1 と、安定版の 6.8.y / 6.17.y / 7.0.y である。

表を上から下まで眺めると、古い系列がきれいに not-affected で埋まっていることが分かる。RHEL は 9 までが全部 Not affected で、10 だけが該当する。Ubuntu は jammy までが not-affected で、noble から該当する。

ここが実務上いちばん誤りやすい点だと思う。「うちは RHEL 9 で止まっているから、こういうのはたいてい該当する」という推定が、この件では逆を向く。逆に「今年 RHEL 10 に上げたばかりだから新しくて安心」という環境が、そのまま対象になる。

外向きかどうかで優先度を決めると外す

ベクタをもう一度見る。AV:L（ローカル）で PR:L（低権限が必要）である。ネットワーク越しに、認証なしで叩けるものではない。

だからといって「外向きのサーバではないから後回し」と置くと、優先度の付け方を間違える。この型の脆弱性が実際に使われるのは、別の入口で一般ユーザ権限を取られた後である。Web アプリの欠陥を踏まれた、コンテナから抜けられた、という状況の続きで、root へ上がるために使われる。侵入の1手目ではなく2手目に置かれる道具だ。

したがって優先度は、外部への露出ではなく「低権限のコード実行が正規の機能として存在するか」で決めるのが合っている。

• マルチテナントで他人のコードを動かすホスト
• CI のランナー（ジョブは事実上、任意のコードである）
• 非特権ユーザにシェルを配っている踏み台や共有開発サーバ
• 非特権コンテナを大量に回しているノード

これらは、外向きの口が一つも開いていなくても優先度が高い。逆に、自分たちしかログインしない単機能サーバは、同じ CVSS でも実質的な危険度が下がる。

コンテナ環境で1つだけ補足しておく。上げるのはノードのカーネルであって、イメージの中のカーネルパッケージではない。コンテナはホストのカーネルを共有するので、イメージ側で kernel パッケージを更新しても何も変わらない。マネージドなノードを使っているなら、修正の入ったノードイメージへの入れ替えが実際の作業になる。

判定を1コマンドに落とす

該当条件は「カーネル系列」と「ディストリの判定」の2つで、どちらもホストの上で確認できる。次のスクリプトは、その2つを見て AFFECTED / NOT-AFFECTED / UNKNOWN のいずれかを返す。

#!/usr/bin/env bash
# CVE-2026-53362 (Linux kernel, IPv6 __ip6_append_data) の該当判定
# 判定できないものは UNKNOWN を返す。分からないものを NOT-AFFECTED に倒さない。
set -uo pipefail

kver="$(uname -r)"
series="$(printf '%s' "$kver" | cut -d. -f1,2)"
id=""; ver=""
if [[ -r /etc/os-release ]]; then
  # shellcheck disable=SC1091
  . /etc/os-release
  id="${ID:-}"; ver="${VERSION_ID:-}"
fi

printf 'kernel : %s (series %s)\n' "$kver" "$series"
printf 'distro : %s %s\n' "${id:-unknown}" "${ver:-unknown}"

verdict="UNKNOWN"
reason="判定表に無い組み合わせ。ディストリのトラッカーで確認すること"

case "$id" in
  rhel|centos|rocky|almalinux)
    case "${ver%%.*}" in
      6|7|8|9) verdict="NOT-AFFECTED"; reason="Red Hat は RHEL 6〜9 を Not affected と判定" ;;
      10)      verdict="AFFECTED";     reason="RHEL 10 系が該当。RHSA-2026:34911 / 35840 を適用" ;;
    esac
    ;;
  ubuntu)
    case "$ver" in
      14.04|16.04|18.04|20.04|22.04)
        verdict="NOT-AFFECTED"; reason="Ubuntu は jammy までを not-affected と判定" ;;
      24.04|24.10|25.04|25.10|26.04)
        verdict="AFFECTED"; reason="noble 以降が該当。提供され次第カーネルを更新して再起動" ;;
    esac
    ;;
  debian)
    case "${ver%%.*}" in
      11) verdict="NOT-AFFECTED"; reason="bullseye は resolved（urgency: unimportant）" ;;
      12) # bookworm は 6.1.177-1 で修正済み。実際の版で比べる
          fixed="6.1.177-1"
          have="$(dpkg-query -W -f='${Version}' "linux-image-$kver" 2>/dev/null || true)"
          if [[ -z "$have" ]]; then
            verdict="UNKNOWN"; reason="稼働中カーネルのパッケージ版を取得できなかった"
          elif dpkg --compare-versions "$have" ge "$fixed"; then
            verdict="NOT-AFFECTED"; reason="bookworm・修正版 $fixed 以降（現在 $have）"
          else
            verdict="AFFECTED"; reason="bookworm・$fixed 未満（現在 $have）。更新して再起動"
          fi
          ;;
    esac
    ;;
esac

printf 'verdict: %s\n' "$verdict"
printf 'reason : %s\n' "$reason"
[[ "$verdict" == "NOT-AFFECTED" ]] && exit 0
[[ "$verdict" == "AFFECTED" ]] && exit 1
exit 2

終了コードは、0 が該当なし、1 が該当、2 が判定不能である。判定不能を 0 にしないのがここでの要点で、判定表に無い組み合わせを「大丈夫」に倒すと、確認していないホストが確認済みの列に紛れる。構成管理から一斉に回すなら、2 を返したホストだけを人が見る、という運用にできる。

uname -r を使っているので、判定するのはいま動いているカーネルである。パッケージだけ更新して再起動していないホストは、正しく AFFECTED のままになる。この件は再起動が要る種類なので、その挙動で合っている。

再起動が取れないとき

Red Hat は kpatch も出している（RHSA-2026:43826）。ライブパッチで先に塞いでおき、再起動は計画停止に合わせる、という順序が取れる。是正期限が3日しかないので、停止調整に時間がかかる本番系ではこの二段構えが現実的だと思う。

回避策として公表されているものは無い。IPv6 を止めれば攻撃面は縮むが、上流もディストリもそれを回避策として示していないので、恒久策として台帳に書かないほうがよい。「対処済み」の欄に、公式でない緩和を書いてしまうと、次に見た人がそれ以上追わなくなる。

まとめ

• IPv6 送信経路の fraggap の計上漏れで、確保より多く書き込まれる。CVSS 3.1 は 7.8 High
• KEV 収載は 2026年8月27日、是正期限は 8月30日
• RHEL 6〜9 と Ubuntu jammy 以前は Not affected。該当するのは RHEL 10 と Ubuntu noble 以降
• AV:L / PR:L なので、優先度は外部露出ではなく「低権限のコード実行が正規に存在するか」で決める
• 判定は「カーネル系列」と「ディストリの判定」の2つ。判定不能は 0 に倒さず、人が見る列へ送る

各クラウド（AWS / GCP / Azure）での対応の整理は CVE Watch の CVE-2026-53362 のページに置いている。