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

CVE-2025-38502

Accesso out-of-bounds alla cgroup local storage di BPF del kernel Linux tramite tail call

Solo per ricerca / uso educativo. Non eseguire, distribuire o utilizzare il materiale presente in questo repository contro qualsiasi host, a meno che tu non abbia esplicita autorizzazione scritta sia dal soggetto che ospita questo repository sia dal proprietario dei sistemi target. Trovato in the wild.

Il nome del file sorgente CVE-2025-3850-Linux-LPE-Abaraxas-Labs.c tronca l'identificatore. Il record pubblicato è CVE-2025-38502. Non esiste alcun CVE Linux CVE-2025-3850.

Contenuti

• Riepilogo
• Impatto
• Causa principale
• Versioni del kernel interessate
• Stato nelle distribuzioni
• Precondizioni
• Il fix
• Verifica di un sistema in esecuzione
• Mitigazione
• Struttura del repository
• Riferimenti
• Contatti
• Disclaimer

Riepilogo

Lonial ha segnalato che la cgroup BPF local storage può essere acceduta out of bounds attraverso una tail call.

Il verifier eBPF esegue il type-check di ciascun programma in isolamento. A runtime, bpf_get_local_storage() non cerca la map del programma attualmente in esecuzione. Legge il puntatore alla cgroup-storage da current->bpf_ctx → bpf_cg_run_ctx → prog_item->cgroup_storage[]. Quello slot viene riempito dal programma originariamente collegato, non dal programma in cui è stata effettuata la tail call.

Se il programma A (con BPF_MAP_TYPE_CGROUP_STORAGE di dimensione value piccola) effettua una tail call verso il programma B (dimensione value grande), la bpf_get_local_storage() di B restituisce comunque il buffer più piccolo di A. Gli accessi che il verifier aveva consentito sulla map di B finiscono quindi oltre la fine dell'allocazione di A.

Il difetto è stato introdotto in Linux 5.9 da 7d9c342 (bpf: Make cgroup storages shared between programs on the same cgroup). È stato corretto estendendo bpf_map_owner con un storage_cookie[], in modo che le combinazioni di tail call siano accettate solo quando il callee usa le stesse cgroup-storage map del caller, oppure non ne usa alcuna.

Impatto

Si tratta di un accesso out-of-bounds locale all'heap del kernel. Il punteggio di severità varia tra i vendor perché non concordano se la primitiva sia un "DoS in sola lettura" o una vera e propria corruzione di memoria:

Cosa significa in pratica:

• Riservatezza. Una lettura OOB dell'oggetto kmalloc adiacente può far trapelare puntatori del kernel (KASLR slide), heap cookie e contenuti di strutture adiacenti.
• Integrità. Lo stesso mismatch è una scrittura dimensionata rispetto alla map del callee, contro il buffer più piccolo del caller. Gli oggetti heap adiacenti (ad esempio una struct bpf_array spruzzata nello stesso slab/order) possono essere corrotti.
• Disponibilità. Una scrittura mal indirizzata è un banale kernel oops / panic.
• Privilegi. Su un kernel non patchato in cui è possibile caricare programmi BPF cgroup, questa classe di heap OOB è stata usata come primitiva di local privilege escalation (sovrascrittura di map->ops, hijack di un helper, commit_creds / cambio di namespace). È per questo che questo repository etichetta il problema come LPE. Il punteggio più basso di Red Hat riflette la loro valutazione specifica per prodotto, non l'assenza del bug.

Il bug non richiede un servizio esposto in rete. È locale. Non richiede una TTY, un helper setuid o l'interazione dell'utente.

Causa principale

Verifier vs runtime

Due programmi BPF cgroup, ciascuno con la propria BPF_MAP_TYPE_CGROUP_STORAGE (variante shared, BPF_CGROUP_STORAGE_SHARED):

Il verifier controlla A rispetto alla map di A e B rispetto alla map di B. Entrambi passano.

A runtime l'helper esegue:

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 è la voce dell'array relativa al programma che ha avviato la cgroup run, non al programma attualmente in esecuzione dopo bpf_tail_call. B opera quindi sull'oggetto storage di A.

Perché le dimensioni contano

bpf_cgroup_storage_alloc() dimensiona il buffer di supporto in base alla value_size della map. Il buffer di A è troppo piccolo per gli accessi verificati di B. Il risultato è una classica type-confusion dell'identità della map attraverso un trasferimento di controllo — la stessa famiglia di bug di altre problematiche BPF in cui "l'helper vede una map diversa da quella vista dal verifier".

Storage condivisa su un cgroup

Il commit 7d9c342 ha reso le cgroup storage condivise tra programmi collegati allo stesso cgroup. È questa condivisione che rende lo slot del run-context un singolo puntatore anziché una ricerca per-programma, ed è il motivo per cui i kernel precedenti alla 5.9 non sono interessati.

Oggetti adiacenti

BPF_PROG_TEST_RUN su un programma BPF_PROG_TYPE_CGROUP_SKB alloca la cgroup storage per la durata del test. Quell'allocazione si trova sull'heap del kernel accanto a qualunque altra cosa sia stata recentemente liberata nella stessa classe di dimensione — incluse map struct bpf_array la cui value_size è stata scelta per ricadere nello stesso kmalloc order. Un OOB dal buffer della storage può quindi raggiungere i campi di bpf_map (ops, lista RCU, value[]) di una array map adiacente.

Questo dettaglio del layout dell'heap è il motivo per cui un advisory di "semplice OOB read" e una trattazione LPE possono descrivere lo stesso CVE.

Versioni del kernel interessate

Introdotto in: Linux 5.9 (7d9c3427894fe70d1347b4820476bf37736d2ff0)
Non interessati: tutti i kernel precedenti alla 5.9

One-liner:

/* 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 */

Ancora aperto in alcuni stable: il kernel tracker di Debian elencava 5.10 upstream-stable / bullseye 5.10 come needed. Non dare per scontato che ogni 5.10.y sia patchato.

I numeri ABI delle distro ingannano. Ubuntu 5.15.0-163 è una 5.15 patchata anche se 5.15.0 sembra più vecchia della upstream 5.15.192. Confronta il changelog del pacchetto / USN / DSA / ALAS / RHSA, non uname -r con la tabella sopra.

Stato nelle distribuzioni

Qualsiasi distribuzione che abbia distribuito un kernel nei range sopra riportati era nello scope finché non ha backportato abad3d0 (o il commit stable corrispondente). Si tratta di codice BPF generico, non di una patch specifica di una distro.

Tipicamente interessate fino alla patch

Non interessate (kernel GA precedente alla 5.9)

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

Versioni note dei pacchetti patchati (esempi)

Ubuntu 26.04 / 25.10 sono elencate come non interessate (si sono diramate dopo il fix). Ubuntu 25.04 ha raggiunto l'EOL ancora needed.

Precondizioni

Un host può corrispondere a una versione interessata e non essere comunque raggiungibile. Verifiche utili:

unprivileged_bpf_disabled=1 non è un fix completo — un utente con capability BPF può comunque colpire il bug — ma rimuove il percorso non privilegiato.

Il fix

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

struct bpf_map_owner acquisisce un array storage_cookie[]. All'aggiornamento del target di una tail call, il kernel ora:

1. Se il callee usa bpf_get_local_storage() — richiede che le cgroup-storage map del callee siano esattamente quelle del caller (stessi cookie).
2. Se il callee non usa alcuna cgroup local storage — consente la combinazione di tail call.

Le dimensioni value non corrispondenti non possono più essere composte alle spalle del verifier. Ogni programma è ancora verificato singolarmente; il nuovo controllo è sul confine tra essi.

Non fare cherry-pick del commit su un albero arbitrario senza gli helper owner/cookie BPF circostanti. Usa il backport stable per la tua serie.

Verifica di un sistema in esecuzione

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)

Conferma il pacchetto, non solo la stringa di versione:

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

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

Un kernel ≥ 6.17, o uno stable elencato nella colonna "prima versione corretta", o un pacchetto della distro dalla tabella degli advisory, è la vera chiusura del caso.

Mitigazione

1. Patcha. Installa il kernel della distro che contiene abad3d0 / l'equivalente stable. Questo è l'unico fix completo.
2. Finché non puoi patchare:
   • Imposta kernel.unprivileged_bpf_disabled=1 (o 2) per eliminare i loader non privilegiati.
   • Limita CAP_BPF, CAP_PERFMON e CAP_SYS_ADMIN per utenti e container non fidati.
   • Nei namespace utente / container non privilegiati, disabilita BPF (seccomp, LSM, o rimuovendo quelle capability nel runtime).
3. Non considerare "non colleghiamo noi stessi programmi cgroup SKB" come una garanzia di sicurezza. BPF_PROG_TEST_RUN è sufficiente per esercitare il percorso di allocazione; è un attaccante locale a fornire i programmi.

Struttura del repository

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

Questa directory documenta la vulnerabilità e contiene il corrispondente albero di ricerca. Non è un exploit kit pronto all'uso: i simboli dei gadget del kernel (ARRAY_MAP_OPS_OFF, COMMIT_CREDS, …) sono input a compile-time per uno specifico vmlinux, e l'esecuzione del programma contro un kernel live è fuori dallo scope di questo README.

Riferimenti

CVE / NVD

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

Upstream

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

Backport stable

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

Distro

• Pagina CVE di Ubuntu
• Security tracker di Debian
• Debian kernel-sec
• Red Hat
• Amazon Linux ALAS
• SUSE

Contatti

Abraxas Labs — solo ricerca / test autorizzati

Disclaimer

Questo repository è destinato a ricerca e formazione.

Non compilare, eseguire, distribuire o altrimenti utilizzare il codice qui presente contro qualsiasi sistema, a meno che tu non abbia esplicita autorizzazione scritta sia dal soggetto che ospita questo repository sia dal proprietario del target. L'accesso non autorizzato a sistemi informatici è un reato.

Gli autori e Abraxas Labs forniscono questo materiale così com'è, senza alcuna garanzia che sia completo, corretto o sicuro da eseguire. La ricerca sullo sfruttamento del kernel può mandare in panic una macchina, corrompere filesystem e causare perdita di dati. Ti assumi questo rischio.

Trovato in the wild.