Abraxas Labs · abraxaslabs.tech · github.com/abraxas · @abraxas_null

CVE-2025-38502

Linux カーネル BPF cgroup ローカルストレージにおけるテールコール経由の境界外アクセス

研究・教育目的のみ。 このリポジトリをホストする当事者と対象システムの所有者の両方から明示的な書面による許可を得ていない限り、このリポジトリ内の資料をいかなるホストに対しても実行、デプロイ、または使用しないでください。実環境で発見されました。

ソースファイル名 CVE-2025-3850-Linux-LPE-Abaraxas-Labs.c は識別子を切り詰めています。公開されたレコードは CVE-2025-38502 です。Linux CVE CVE-2025-3850 は存在しません。

目次

• 概要
• 影響
• 根本原因
• 影響を受けるカーネルバージョン
• ディストリビューションの状況
• 前提条件
• 修正
• 稼働中システムの確認
• 緩和策
• リポジトリ構成
• 参考文献
• 連絡先
• 免責事項

概要

Lonial は、cgroup BPF ローカルストレージがテールコールをまたいで境界外アクセスされる可能性があることを報告しました。

eBPF 検証器は各プログラムを個別に型チェックします。実行時、bpf_get_local_storage() は現在実行中のプログラムのマップを参照しません。cgroup ストレージポインタを current->bpf_ctx → bpf_cg_run_ctx → prog_item->cgroup_storage[] から読み取ります。このスロットは、テールコールされた先のプログラムではなく、元々アタッチされたプログラムから設定されます。

プログラム A (小さい BPF_MAP_TYPE_CGROUP_STORAGE の値サイズ) がプログラム B (大きい値サイズ) をテールコールする場合、B の bpf_get_local_storage() は依然として A のより小さいバッファを返します。検証器が B のマップに対して許可したアクセスは、A のアロケーションの終端を越えてしまいます。

この欠陥は Linux 5.9 で 7d9c342 (bpf: Make cgroup storages shared between programs on the same cgroup) によって導入されました。bpf_map_owner に storage_cookie[] を追加することで修正され、テールコールの組み合わせは、呼び出し先が呼び出し元と同じ cgroup ストレージマップを使用するか、まったく使用しない場合にのみ受け入れられるようになりました。

影響

これはローカルカーネルヒープの境界外アクセスです。深刻度のスコアリングは、このプリミティブを「読み取り専用 DoS」と見なすか完全なメモリ破壊と見なすかでベンダー間で見解が分かれるため、異なります。

実際にはこれが意味すること:

• 機密性。 隣接する kmalloc オブジェクトの OOB 読み取りにより、カーネルポインタ (KASLR スライド)、ヒープクッキー、および隣接構造体の内容が漏洩する可能性があります。
• 完全性。 同じ不一致は、呼び出し元のより小さいバッファに対する、呼び出し先のマップを基準としたサイズ付き書き込みです。隣接するヒープオブジェクト (例えば同じ slab/order にスプレーされた struct bpf_array) が破壊される可能性があります。
• 可用性。 誤ったターゲットへの書き込みは、単純なカーネル oops / panic を引き起こします。
• 権限。 BPF cgroup プログラムをロードできる未パッチのカーネルでは、このクラスのヒープ OOB はローカル権限昇格プリミティブとして使用されてきました (map->ops の上書き、ヘルパーのハイジャック、commit_creds / 名前空間切り替え)。これがこのツリーがこの問題を LPE とラベル付けする理由です。Red Hat のより低いスコアは、バグの不在ではなく、製品固有の評価を反映しています。

このバグはネットワークに面したサービスを必要としません。ローカルです。TTY、setuid ヘルパー、またはユーザー操作を必要としません。

根本原因

検証器 vs 実行時

2 つの cgroup BPF プログラム、それぞれが独自の BPF_MAP_TYPE_CGROUP_STORAGE (共有フレーバー、BPF_CGROUP_STORAGE_SHARED) を持ちます:

検証器は A を A のマップに対して、B を B のマップに対してチェックします。両方とも合格します。

実行時、ヘルパーは以下を実行します:

ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
storage = ctx->prog_item->cgroup_storage[stype];
if (stype == BPF_CGROUP_STORAGE_SHARED)
    ptr = &READ_ONCE(storage->buf)->data[0];
else
    ptr = this_cpu_ptr(storage->percpu_buf);

prog_item は、bpf_tail_call 後に現在実行中のプログラムではなく、cgroup 実行を開始したプログラムの配列エントリです。したがって B は A のストレージオブジェクトを操作します。

サイズが重要である理由

bpf_cgroup_storage_alloc() は、マップの value_size からバッキングバッファのサイズを決定します。A のバッファは B の検証済みアクセスに対して小さすぎます。結果は、制御転送をまたいだマップ同一性の古典的な型混同です。これは、他の BPF の「ヘルパーが検証器とは異なるマップを見る」問題と同じファミリーのバグです。

cgroup 上の共有ストレージ

コミット 7d9c342 は、cgroup ストレージを同じ cgroup にアタッチされたプログラム間で共有するようにしました。この共有により、実行コンテキストのスロットがプログラムごとのルックアップではなく単一のポインタになり、5.9 より前のカーネルが影響を受けない理由となっています。

隣接オブジェクト

BPF_PROG_TYPE_CGROUP_SKB プログラムに対する BPF_PROG_TEST_RUN は、テスト期間中 cgroup ストレージを割り当てます。このアロケーションは、同じサイズクラスで最近解放された他のものの隣のカーネルヒープ上に位置します — 例えば、同じ kmalloc order に収まるように value_size が選ばれた struct bpf_array マップを含みます。したがって、ストレージバッファからの OOB は、隣接する配列マップの bpf_map フィールド (ops、RCU リスト、value[]) に到達する可能性があります。

このヒープレイアウトの詳細が、「単なる OOB 読み取り」のアドバイザリと LPE の解説が同じ CVE を説明できる理由です。

影響を受けるカーネルバージョン

導入: Linux 5.9 (7d9c3427894fe70d1347b4820476bf37736d2ff0)
影響なし: 5.9 より前のすべてのカーネル

ワンライナー:

/* CVE-2025-38502: affected 5.9–5.15.191, 5.16–6.1.150, 6.2–6.6.104, 6.7–6.12.45, 6.13–6.16.0; fixed in 5.15.192, 6.1.151, 6.6.105, 6.12.46, 6.16.1, 6.17-rc1 */

一部の stable では依然未修正: Debian のカーネルトラッカーは 5.10 アップストリーム stable / bullseye 5.10 を needed と記載していました。すべての 5.10.y がパッチ済みであると仮定しないでください。

ディストロの ABI 番号は当てになりません。 Ubuntu 5.15.0-163 は、5.15.0 がアップストリーム 5.15.192 より古く見えても、パッチ済みの 5.15 です。上の表と uname -r を比較するのではなく、パッケージの changelog / USN / DSA / ALAS / RHSA を比較してください。

ディストリビューションの状況

上記の範囲のカーネルを出荷したディストリビューションは、abad3d0 (または対応する stable コミット) をバックポートするまで対象でした。これはディストロ固有のパッチではなく、汎用 BPF コードです。

パッチが当たるまで通常影響を受ける

影響なし (5.9 より古い GA カーネル)

• Ubuntu 20.04 GA (5.4)、18.04、16.04
• RHEL 8 デフォルト (4.18)
• Amazon Linux 1、Amazon Linux 2 core / 5.4 extra

既知のパッチ済みパッケージバージョン (例)

Ubuntu 26.04 / 25.10 は影響なしと記載されています (修正後にブランチしたため)。Ubuntu 25.04 は EOL に達しても needed のままです。

前提条件

ホストが影響を受けるバージョンに一致しても、到達可能でない場合があります。有用なチェック:

unprivileged_bpf_disabled=1 は完全な修正ではありません — BPF ケイパビリティを持つユーザーは依然としてこのバグに到達できます — が、非特権パスを排除します。

修正

アップストリームコミット abad3d0bad72a52137e0c350c59542d75ae4f513 (bpf: Fix oob access in cgroup local storage、Daniel Borkmann)。

struct bpf_map_owner に storage_cookie[] 配列が追加されます。テールコール先の更新時に、カーネルは以下を行います:

1. 呼び出し先が bpf_get_local_storage() を使用する場合 — 呼び出し先の cgroup ストレージマップが呼び出し元のマップと完全に同じ (同じクッキー) であることを要求します。
2. 呼び出し先が cgroup ローカルストレージを使用しない場合 — テールコールの組み合わせを許可します。

値サイズの不一致は、検証器の背後で合成できなくなりました。各プログラムは依然として単独で検証されますが、新しいチェックはそれらの間のエッジにあります。

周囲の BPF owner/cookie ヘルパーなしで、任意のツリーにコミットをチェリーピックしないでください。お使いのシリーズ用の stable バックポートを使用してください。

稼働中システムの確認

uname -r
# Compare against the table above, then against your distro advisory —
# Ubuntu/Debian ABI numbers are not upstream stable numbers.

grep -E 'CONFIG_BPF_SYSCALL|CONFIG_CGROUP_BPF' \
  /boot/config-$(uname -r) /proc/config.gz 2>/dev/null

sysctl kernel.unprivileged_bpf_disabled
# 0  = unprivileged bpf allowed (widest exposure)
# 1  = disabled after first privileged use, or fully disabled depending on kernel
# 2  = disabled (admin can re-enable)

バージョン文字列だけでなく、パッケージを確認してください:

# Debian / Ubuntu
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i 38502

# RHEL family
rpm -q --changelog kernel | grep -i 38502

カーネル ≥ 6.17、または「最初の修正」列に記載された stable、またはアドバイザリ表のディストロパッケージが、実際のクローズアウトです。

緩和策

1. パッチ。 abad3d0 / stable 相当を含むディストロカーネルをインストールします。これが唯一の完全な修正です。
2. パッチを当てるまでの間:
   • kernel.unprivileged_bpf_disabled=1 (または 2) を設定して、非特権ローダーを排除します。
   • 信頼できないユーザーとコンテナに対して CAP_BPF、CAP_PERFMON、CAP_SYS_ADMIN を制限します。
   • ユーザー名前空間 / 非特権コンテナでは、BPF を無効にします (seccomp、LSM、またはランタイムでこれらのケイパビリティを削除)。
3. 「私たち自身は cgroup SKB プログラムをアタッチしない」ことを安全と見なさないでください。BPF_PROG_TEST_RUN だけでアロケーションパスを実行するのに十分です。ローカル攻撃者がプログラムを提供します。

リポジトリ構成

CVE-2025-38502/
├── README.md
├── banner.png
├── CVE-2025-3850-Linux-LPE-Abaraxas-Labs.c
└── ebpf_lpe.h

このディレクトリは脆弱性を文書化し、対応する研究ツリーを保持しています。これはすぐに使えるエクスプロイトキットではありません: カーネルギャジェットシンボル (ARRAY_MAP_OPS_OFF、COMMIT_CREDS、…) は特定の vmlinux 用のコンパイル時入力であり、稼働中のカーネルに対してプログラムを実行することはこの README の範囲外です。

参考文献

CVE / NVD

• CVE-2025-38502
• NVD
• GitHub Advisory GHSA-x96j-4m6x-jcvx

アップストリーム

• 導入: 7d9c342 — bpf: Make cgroup storages shared between programs on the same cgroup
• 修正: abad3d0 — bpf: Fix oob access in cgroup local storage
• linux-cve-announce

Stable バックポート

• 6.16.1 19341d5c
• 6.12.46 41688d1f
• 6.6.105 7acfa07c
• 6.1.151 66da7cee
• 5.15.192 c1c74584

ディストロ

• Ubuntu CVE ページ
• Debian セキュリティトラッカー
• Debian kernel-sec
• Red Hat
• Amazon Linux ALAS
• SUSE

連絡先

Abraxas Labs — 研究 / 許可されたテストのみ

免責事項

このリポジトリは研究と教育のためのものです。

このリポジトリをホストする当事者と対象の所有者の両方から明示的な書面による許可を得ていない限り、ここにあるコードをいかなるシステムに対してもコンパイル、実行、デプロイ、またはその他の方法で使用しないでください。コンピュータシステムへの不正アクセスは犯罪です。

著者および Abraxas Labs は、この資料を現状のまま提供し、完全、正確、または実行しても安全であるという保証はありません。カーネルエクスプロイト研究は、マシンをパニックさせ、ファイルシステムを破壊し、データを失う可能性があります。そのリスクはあなたが負います。

実環境で発見されました。