CVE-2026-53266 — ebtables SNAT の境界外書き込みを、自分のカーネルで確かめる

CISA が 2026-09-18 に KEV（悪用が確認された脆弱性カタログ）へ追加した CVE-2026-53266 は、Linux カーネルの netfilter bridge、いわゆる ebtables の SNAT ターゲットにある境界外書き込みである。是正期限は 2026-09-21 と短い。

CVSS 3.1 は 8.8 High、ベクタは AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H。CWE は CWE-787（Out-of-bounds Write）。

何が起きているか

NVD に載っている説明はカーネルのコミットメッセージそのままで、要点は次の1文である。

“In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable.”

ebtables の SNAT ターゲットは、Ethernet ヘッダの送信元アドレスを書き換える処理を skb_ensure_writable(skb, 0) の後ろに置いている。ところがオプションである ARP の送信元ハードウェアアドレスの書き換えが、それとは別の場所を触っていた。Ubuntu のセキュリティトラッカーは、非線形な skb に対して、splice で取り込まれたページへ書き込みチェックを通さずに直接書いてしまう可能性があると説明している。

ベクタの読み方が大事なところである。

• AV:L（Local） — リモートから直接叩ける類ではない。ネットワーク越しのパケットを送るだけでは発火しない。
• PR:L（低い権限が必要） — ebtables のルールを入れられる権限、つまり実質 CAP_NET_ADMIN が要る。
• S:C（Scope Changed） — ここが効いている。ユーザー名前空間の中で CAP_NET_ADMIN を持てる構成なら、非特権ユーザーが名前空間の外側へ影響を及ぼせるという意味になる。コンテナを動かしているホストで効いてくるのはこの1文字である。

「ローカルだから後回し」と読むと判断を誤る。S:C が付いた LPE は、コンテナや CI ランナーのようにユーザーの用意したコードを走らせる箱で重い。

自分の環境が該当するかを確かめる

パッチ適用の判断は、次の3点で切り分けられる。上から順に見ていけば、多くの環境は途中で「対象外」と分かる。

1. カーネルのバージョン

uname -r
cat /proc/version

Ubuntu の場合、修正が入っているのは 26.04 LTS（resolute）の linux 7.0.0-31.31 と、24.04 LTS 向けの linux-hwe-7.0 7.0.0-31.31~24.04.1 およびクラウド各派生である。22.04 LTS（jammy）と 20.04 LTS（focal）の各カーネルは、この記事を書いている時点でまだ Work in Progress として残っている。18.04 以前の linux 本体は Not Affected とされている。

ディストリごとに採番が違うので、上流のバージョン番号ではなくパッケージのバージョンで確認するのが確実である。

# Debian / Ubuntu
apt-cache policy linux-image-$(uname -r)
# RHEL 系
rpm -q kernel

2. ebtables / bridge netfilter が実際に使われているか

モジュールが読み込まれていなければ、この経路は動かない。

lsmod | grep -E 'ebtable|br_netfilter|bridge'

何も出なければ、少なくとも現時点ではこのコードパスに入らない。ただしコンテナランタイムやネットワークプラグインが後から読み込むことがあるので、「今は出ていない」を「使っていない」と読み替えないこと。

3. SNAT ターゲットのルールが入っているか

# 従来の ebtables
sudo ebtables -t nat -L 2>/dev/null

# nftables に寄せている環境
sudo nft list table bridge nat 2>/dev/null
sudo nft list ruleset 2>/dev/null | grep -A3 'table bridge'

snat を含む行があれば、まさに該当する処理を通している。

4. ユーザー名前空間から CAP_NET_ADMIN を取れるか

S:C が効く条件がここにある。非特権ユーザーがユーザー名前空間を作れる設定かどうかを見る。

# Debian / Ubuntu
sysctl kernel.unprivileged_userns_clone 2>/dev/null
# 共通（0 なら作れない）
cat /proc/sys/user/max_user_namespaces

kernel.unprivileged_userns_clone が 1、あるいは max_user_namespaces が 0 より大きいなら、非特権ユーザーが名前空間の中で CAP_NET_ADMIN を得られる。ここを閉じられる環境なら、パッチ適用までの時間稼ぎになる。

# 一時的に閉じる（再起動で戻る）
sudo sysctl -w kernel.unprivileged_userns_clone=0

ただしこれは回避策であって修正ではない。コンテナランタイムや一部のブラウザのサンドボックスがユーザー名前空間に依存しているため、閉じると壊れるものがある。本番で入れる前に必ず検証環境で確かめること。

修正コミットを直接読む

NVD の参照には git.kernel.org/stable/ のコミットが8本並んでいる。stable の各系列に同じ修正が backport された結果なので、自分の使っている系列に対応するコミットを選ぶ。

# 例: 自分の系列に入っているかを確かめる
git log --oneline -1 --grep='ebt_snat' v6.17.y

手元にカーネルツリーが無ければ、コミットハッシュを https://git.kernel.org/stable/c/<hash> に当てればブラウザで読める。差分は小さく、skb_ensure_writable の呼び出し位置を直しているだけなので、何が起きていたかは差分を見るのが早い。

まとめ

• AV:L でも S:C が付いていれば、箱を貸している環境では重い。 コンテナホスト、CI ランナー、共有開発サーバが優先対象になる。
• 該当判定は「カーネルのバージョン」だけで終わらせず、ebtables が実際に読み込まれているか、SNAT ルールがあるかまで見ると、対象を絞れる。
• 回避策として非特権ユーザー名前空間を閉じる手はあるが、壊れるものがあるので本番前に検証する。

CVE の追跡はCVE Watchでも日次で更新している。KEV 入りと是正期限は、このサイトの各ページからも辿れる。

---

出典（いずれも 2026-09-20 に確認）

• NVD: CVE-2026-53266（CVSS 8.8 / CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H / CWE-787）
• CISA KEV カタログ（catalogVersion 2026.09.18）: 追加日 2026-09-18、是正期限 2026-09-21、ランサムウェア利用は Unknown
• Ubuntu Security: CVE-2026-53266（優先度 High、修正済みパッケージと未修正の系列）