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

CVE-2025-38502

Acesso fora dos limites ao armazenamento local de cgroup do BPF do kernel Linux via tail calls

Apenas para pesquisa / uso educacional. Não execute, implante ou use o material deste repositório contra qualquer host, a menos que você tenha permissão explícita por escrito tanto da parte que hospeda este repositório quanto do proprietário dos sistemas-alvo. Encontrado em ambiente real.

O nome do arquivo de origem CVE-2025-3850-Linux-LPE-Abaraxas-Labs.c trunca o identificador. O registro publicado é CVE-2025-38502. Não existe CVE do Linux CVE-2025-3850.

Conteúdo

• Resumo
• Impacto
• Causa raiz
• Versões do kernel afetadas
• Status nas distribuições
• Pré-condições
• A correção
• Verificando um sistema em execução
• Mitigação
• Estrutura do repositório
• Referências
• Contato
• Aviso legal

Resumo

Lonial relatou que o armazenamento local de cgroup do BPF pode ser acessado fora dos limites através de uma tail call.

O verificador do eBPF faz a checagem de tipos de cada programa isoladamente. Em tempo de execução, bpf_get_local_storage() não consulta o mapa do programa atualmente em execução. Ele lê o ponteiro do armazenamento de cgroup de current->bpf_ctx → bpf_cg_run_ctx → prog_item->cgroup_storage[]. Esse slot é preenchido a partir do programa originalmente anexado, não do programa para o qual foi feita a tail call.

Se o programa A (com tamanho de valor pequeno em BPF_MAP_TYPE_CGROUP_STORAGE) faz uma tail call para o programa B (com tamanho de valor grande), o bpf_get_local_storage() de B ainda retorna o buffer menor de A. Os acessos que o verificador permitiu em relação ao mapa de B então ultrapassam o fim da alocação de A.

O defeito foi introduzido no Linux 5.9 por 7d9c342 (bpf: Make cgroup storages shared between programs on the same cgroup). Foi corrigido estendendo bpf_map_owner com um storage_cookie[], de modo que combinações de tail call só são aceitas quando o chamado usa os mesmos mapas de armazenamento de cgroup que o chamador, ou não usa nenhum.

Impacto

Este é um acesso fora dos limites no heap do kernel local. A pontuação de severidade varia por fornecedor porque eles discordam sobre se a primitiva é “DoS somente leitura” ou corrupção total de memória:

O que isso significa na prática:

• Confidencialidade. Uma leitura OOB do objeto kmalloc vizinho pode vazar ponteiros do kernel (deslocamento do KASLR), cookies do heap e conteúdos de estruturas adjacentes.
• Integridade. A mesma incompatibilidade é uma escrita dimensionada em relação ao mapa do chamado, contra o buffer menor do chamador. Objetos adjacentes do heap (por exemplo, um struct bpf_array pulverizado na mesma slab/ordem) podem ser corrompidos.
• Disponibilidade. Uma escrita com alvo errado é um oops / panic direto do kernel.
• Privilégio. Em um kernel não corrigido onde programas BPF de cgroup podem ser carregados, essa classe de OOB no heap tem sido usada como primitiva de escalonamento de privilégios local (sobrescrever map->ops, sequestrar um helper, commit_creds / troca de namespace). É por isso que esta árvore rotula o problema como LPE. A pontuação mais baixa do Red Hat reflete sua avaliação específica de produto, não a ausência do bug.

O bug não exige um serviço exposto à rede. É local. Não exige um TTY, um helper setuid ou interação do usuário.

Causa raiz

Verificador vs tempo de execução

Dois programas BPF de cgroup, cada um com seu próprio BPF_MAP_TYPE_CGROUP_STORAGE (variante compartilhada, BPF_CGROUP_STORAGE_SHARED):

O verificador checa A em relação ao mapa de A e B em relação ao mapa de B. Ambos passam.

Em tempo de execução, o helper faz:

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 é a entrada do array para o programa que iniciou a execução do cgroup, não o programa atualmente em execução após bpf_tail_call. Portanto, B opera sobre o objeto de armazenamento de A.

Por que os tamanhos importam

bpf_cgroup_storage_alloc() dimensiona o buffer de suporte a partir do value_size do mapa. O buffer de A é pequeno demais para os acessos verificados de B. O resultado é uma clássica confusão de tipo da identidade do mapa através de uma transferência de controle — a mesma família de bugs de outros problemas de BPF em que “o helper vê um mapa diferente do que o verificador viu”.

Armazenamento compartilhado em um cgroup

O commit 7d9c342 tornou os armazenamentos de cgroup compartilhados entre programas anexados ao mesmo cgroup. Esse compartilhamento é o que faz o slot do contexto de execução ser um único ponteiro em vez de uma consulta por programa, e é por isso que kernels anteriores ao 5.9 não são afetados.

Objetos adjacentes

BPF_PROG_TEST_RUN em um programa BPF_PROG_TYPE_CGROUP_SKB aloca armazenamento de cgroup durante o teste. Essa alocação fica no heap do kernel ao lado de qualquer outra coisa recentemente liberada na mesma classe de tamanho — incluindo mapas struct bpf_array cujo value_size foi escolhido para cair na mesma ordem de kmalloc. Um OOB a partir do buffer de armazenamento pode, portanto, alcançar campos de bpf_map (ops, lista RCU, value[]) de um mapa de array vizinho.

Esse detalhe de layout do heap é o motivo pelo qual um aviso de “mera leitura OOB” e um relatório de LPE podem descrever o mesmo CVE.

Versões do kernel afetadas

Introduzido: Linux 5.9 (7d9c3427894fe70d1347b4820476bf37736d2ff0)
Não afetados: todos os kernels anteriores ao 5.9

Em uma linha:

/* CVE-2025-38502: afeta 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; corrigido em 5.15.192, 6.1.151, 6.6.105, 6.12.46, 6.16.1, 6.17-rc1 */

Ainda aberto em alguns stables: o rastreador de kernel do Debian listava o 5.10 upstream-stable / bullseye 5.10 como needed. Não presuma que todo 5.10.y está corrigido.

Números de ABI de distro enganam. O Ubuntu 5.15.0-163 é um 5.15 corrigido, embora 5.15.0 pareça mais antigo que o upstream 5.15.192. Compare o changelog do pacote / USN / DSA / ALAS / RHSA, não o uname -r com a tabela acima.

Status nas distribuições

Qualquer distribuição que tenha enviado um kernel nas faixas acima estava no escopo até fazer backport de abad3d0 (ou do commit stable correspondente). Este é código BPF genérico, não um patch específico de distro.

Tipicamente afetadas até serem corrigidas

Não afetadas (kernel GA mais antigo que 5.9)

• Ubuntu 20.04 GA (5.4), 18.04, 16.04
• RHEL 8 padrão (4.18)
• Amazon Linux 1; Amazon Linux 2 core / extra 5.4

Versões de pacote corrigidas conhecidas (exemplos)

Ubuntu 26.04 / 25.10 estão listados como não afetados (eles derivaram após a correção). O Ubuntu 25.04 chegou ao EOL ainda needed.

Pré-condições

Um host pode corresponder a uma versão afetada e ainda assim não ser alcançável. Verificações úteis:

unprivileged_bpf_disabled=1 não é uma correção completa — um usuário com capacidade BPF ainda pode atingir o bug — mas remove o caminho sem privilégios.

A correção

Commit upstream abad3d0bad72a52137e0c350c59542d75ae4f513 (bpf: Fix oob access in cgroup local storage, Daniel Borkmann).

struct bpf_map_owner ganha um array storage_cookie[]. Na atualização do alvo da tail call, o kernel agora:

1. Se o chamado usa bpf_get_local_storage() — exige que os mapas de armazenamento de cgroup do chamado sejam exatamente os mapas do chamador (mesmos cookies).
2. Se o chamado não usa armazenamento local de cgroup — permite a combinação de tail call.

Tamanhos de valor incompatíveis não podem mais ser compostos pelas costas do verificador. Cada programa ainda é verificado isoladamente; a nova checagem está na aresta entre eles.

Não faça cherry-pick do commit em uma árvore arbitrária sem os helpers de owner/cookie do BPF ao redor. Use o backport stable para a sua série.

Verificando um sistema em execução

uname -r
# Compare com a tabela acima e depois com o aviso da sua distro —
# números de ABI do Ubuntu/Debian não são números stable do upstream.

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

sysctl kernel.unprivileged_bpf_disabled
# 0  = bpf sem privilégios permitido (exposição mais ampla)
# 1  = desabilitado após o primeiro uso privilegiado, ou totalmente desabilitado dependendo do kernel
# 2  = desabilitado (admin pode reabilitar)

Confirme o pacote, não apenas a string de versão:

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

# Família RHEL
rpm -q --changelog kernel | grep -i 38502

Um kernel ≥ 6.17, ou um stable listado na coluna “primeira correção”, ou um pacote de distro da tabela de avisos, é o fechamento real.

Mitigação

1. Corrija. Instale o kernel da distro que contém abad3d0 / o equivalente stable. Esta é a única correção completa.
2. Até poder corrigir:
   • Defina kernel.unprivileged_bpf_disabled=1 (ou 2) para eliminar carregadores sem privilégios.
   • Restrinja CAP_BPF, CAP_PERFMON e CAP_SYS_ADMIN para usuários e contêineres não confiáveis.
   • Em namespaces de usuário / contêineres sem privilégios, desabilite o BPF (seccomp, LSM ou removendo essas capacidades no runtime).
3. Não trate “nós não anexamos programas cgroup SKB” como segurança. BPF_PROG_TEST_RUN é suficiente para exercitar o caminho de alocação; um atacante local fornece os programas.

Estrutura do repositório

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

Este diretório documenta a vulnerabilidade e contém a árvore de pesquisa correspondente. Não é um kit de exploit pronto para uso: símbolos de gadget do kernel (ARRAY_MAP_OPS_OFF, COMMIT_CREDS, …) são entradas de tempo de compilação para um vmlinux específico, e executar o programa contra um kernel em produção está fora do escopo deste README.

Referências

CVE / NVD

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

Upstream

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

Backports stable

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

Distros

• Página do CVE no Ubuntu
• Rastreador de segurança do Debian
• Debian kernel-sec
• Red Hat
• Amazon Linux ALAS
• SUSE

Contato

Abraxas Labs — apenas pesquisa / testes autorizados

Aviso legal

Este repositório é para pesquisa e educação.

Não compile, execute, implante ou use de qualquer outra forma o código aqui contra qualquer sistema, a menos que você tenha autorização explícita por escrito tanto da parte que hospeda este repositório quanto do proprietário do alvo. Acesso não autorizado a sistemas de computador é crime.

Os autores e a Abraxas Labs fornecem este material como está, sem garantia de que seja completo, correto ou seguro para execução. Pesquisa de exploração de kernel pode causar panic em uma máquina, corromper sistemas de arquivos e perder dados. Você assume esse risco.

Encontrado em ambiente real.