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

CVE-2025-38502

Выход за границы доступа к локальному хранилищу cgroup BPF в ядре Linux через хвостовые вызовы

Только для исследований / образовательных целей. Не запускайте, не разворачивайте и не используйте материалы из этого репозитория против любого хоста без явного письменного разрешения как от стороны, размещающей этот репозиторий, так и от владельца целевых систем. Обнаружено в дикой природе.

Имя исходного файла CVE-2025-3850-Linux-LPE-Abaraxas-Labs.c обрезает идентификатор. Опубликованная запись — CVE-2025-38502. CVE Linux 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 (большой размер значения), bpf_get_local_storage() программы B всё равно возвращает меньший буфер программы 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 может раскрыть указатели ядра (смещение KASLR), куки кучи и содержимое смежных структур.
• Целостность. То же несоответствие представляет собой запись размером относительно карты вызываемой программы в меньший буфер вызывающей. Смежные объекты кучи (например, struct bpf_array, размещённый в том же slab/порядке) могут быть повреждены.
• Доступность. Запись не по адресу — это прямой kernel oops / panic.
• Привилегии. На неисправленном ядре, где можно загружать BPF-программы cgroup, этот класс выхода за границы кучи использовался как примитив локального повышения привилегий (перезапись map->ops, перехват хелпера, commit_creds / переключение пространства имён). Именно поэтому это дерево помечает проблему как LPE. Более низкая оценка Red Hat отражает их оценку для конкретного продукта, а не отсутствие ошибки.

Ошибка не требует сетевого сервиса. Она локальная. Она не требует TTY, setuid-хелпера или взаимодействия с пользователем.

Первопричина

Верификатор против времени выполнения

Две BPF-программы cgroup, каждая со своей 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 — это элемент массива для программы, запустившей выполнение cgroup, а не для программы, исполняемой в данный момент после bpf_tail_call. Таким образом, B работает с объектом хранилища A.

Почему размеры имеют значение

bpf_cgroup_storage_alloc() определяет размер резервного буфера из value_size карты. Буфер A слишком мал для проверенных обращений B. Результат — классическая путаница типов идентичности карты при передаче управления — то же семейство ошибок, что и другие проблемы BPF, когда «хелпер видит не ту карту, что верификатор».

Разделяемое хранилище в cgroup

Коммит 7d9c342 сделал хранилища cgroup разделяемыми между программами, привязанными к одной cgroup. Именно это разделение делает слот в контексте выполнения единым указателем, а не поиском по каждой программе, и поэтому ядра до 5.9 не затронуты.

Смежные объекты

BPF_PROG_TEST_RUN для программы BPF_PROG_TYPE_CGROUP_SKB выделяет хранилище cgroup на время теста. Это выделение располагается в куче ядра рядом с тем, что недавно было освобождено в том же классе размеров — включая карты struct bpf_array, чей value_size был выбран так, чтобы попасть в тот же порядок kmalloc. Поэтому выход за границы буфера хранилища может достичь полей bpf_map (ops, список RCU, value[]) соседней array-карты.

Эта деталь компоновки кучи объясняет, почему рекомендация о «простом чтении за границами» и описание 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 */

Всё ещё открыто в некоторых стабильных ветках: трекер ядра Debian указывал 5.10 upstream-stable / bullseye 5.10 как needed. Не предполагайте, что каждое 5.10.y исправлено.

ABI-номера дистрибутивов обманчивы. Ubuntu 5.15.0-163 — это исправленное 5.15, хотя 5.15.0 выглядит старее, чем upstream 5.15.192. Сравнивайте changelog пакета / USN / DSA / ALAS / RHSA, а не uname -r с таблицей выше.

Статус в дистрибутивах

Любой дистрибутив, поставлявший ядро в указанных выше диапазонах, был в зоне риска до тех пор, пока не бэкпортировал abad3d0 (или соответствующий стабильный коммит). Это общий код BPF, а не патч конкретного дистрибутива.

Обычно затронуты до исправления

Не затронуты (GA-ядро старше 5.9)

• 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 всё ещё может вызвать ошибку — но это устраняет непривилегированный путь.

Исправление

Upstream-коммит 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 — разрешает комбинацию хвостового вызова.

Несоответствующие размеры значений больше не могут быть скомпонованы за спиной верификатора. Каждая программа по-прежнему проверяется отдельно; новая проверка находится на ребре между ними.

Не применяйте коммит cherry-pick к произвольному дереву без окружающих хелперов owner/cookie для BPF. Используйте стабильный бэкпорт для вашей ветки.

Проверка работающей системы

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, или стабильная версия из столбца «первое исправление», или пакет дистрибутива из таблицы рекомендаций — это фактическое закрытие вопроса.

Меры защиты

1. Патч. Установите ядро дистрибутива, содержащее abad3d0 / стабильный эквивалент. Это единственное полное исправление.
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

Upstream

• Внесено: 7d9c342 — bpf: Make cgroup storages shared between programs on the same cgroup
• Исправлено: abad3d0 — bpf: Fix oob access in cgroup local storage
• linux-cve-announce

Стабильные бэкпорты

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

Дистрибутивы

• Страница CVE в Ubuntu
• Трекер безопасности Debian
• Debian kernel-sec
• Red Hat
• Amazon Linux ALAS
• SUSE

Контакты

Abraxas Labs — только исследования / авторизованное тестирование

Отказ от ответственности

Этот репозиторий предназначен для исследований и образования.

Не компилируйте, не запускайте, не разворачивайте и не используйте иным образом код отсюда против любой системы, если у вас нет явного письменного разрешения как от стороны, размещающей этот репозиторий, так и от владельца цели. Несанкционированный доступ к компьютерным системам является преступлением.

Авторы и Abraxas Labs предоставляют этот материал как есть, без каких-либо гарантий того, что он полон, корректен или безопасен для выполнения. Исследования по эксплуатации ядра могут привести к панике машины, повреждению файловых систем и потере данных. Вы принимаете этот риск.

Обнаружено в дикой природе.