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

CVE-2025-38502

Accès hors limites au stockage local de cgroup BPF du noyau Linux via des tail calls

Usage recherche / éducatif uniquement. N'exécutez, ne déployez et n'utilisez le contenu de ce dépôt contre aucun hôte sans autorisation écrite explicite de la part à la fois de la partie hébergeant ce dépôt et du propriétaire des systèmes cibles. Trouvé dans la nature.

Le nom de fichier source CVE-2025-3850-Linux-LPE-Abaraxas-Labs.c tronque l'identifiant. L'enregistrement publié est CVE-2025-38502. Il n'existe pas de CVE Linux CVE-2025-3850.

Sommaire

• Résumé
• Impact
• Cause racine
• Versions du noyau affectées
• Statut de distribution
• Préconditions
• Le correctif
• Vérification d'un système en cours d'exécution
• Atténuation
• Organisation du dépôt
• Références
• Contact
• Avertissement

Résumé

Lonial a signalé que le stockage local de cgroup BPF peut être accédé hors limites à travers un tail call.

Le vérificateur eBPF effectue la vérification de type de chaque programme isolément. À l'exécution, bpf_get_local_storage() ne recherche pas la map du programme en cours d'exécution. Il lit le pointeur de stockage de cgroup depuis current->bpf_ctx → bpf_cg_run_ctx → prog_item->cgroup_storage[]. Cet emplacement est rempli à partir du programme initialement attaché, et non du programme vers lequel un tail call a été effectué.

Si le programme A (petite taille de valeur BPF_MAP_TYPE_CGROUP_STORAGE) effectue un tail call vers le programme B (grande taille de valeur), le bpf_get_local_storage() de B renvoie toujours le plus petit tampon de A. Les accès que le vérificateur a autorisés par rapport à la map de B dépassent alors la fin de l'allocation de A.

Le défaut a été introduit dans Linux 5.9 par 7d9c342 (bpf: Make cgroup storages shared between programs on the same cgroup). Il a été corrigé en étendant bpf_map_owner avec un storage_cookie[] afin que les combinaisons de tail calls ne soient acceptées que lorsque le programme appelé utilise les mêmes maps de stockage de cgroup que l'appelant, ou n'en utilise aucune.

Impact

Il s'agit d'un accès hors limites au tas du noyau local. Le score de gravité varie selon l'éditeur car ils ne sont pas d'accord sur le fait que la primitive soit un « DoS en lecture seule » ou une corruption mémoire complète :

Ce que cela signifie en pratique :

• Confidentialité. Une lecture hors limites de l'objet kmalloc voisin peut divulguer des pointeurs du noyau (décalage KASLR), des cookies de tas et le contenu des structures adjacentes.
• Intégrité. La même inadéquation est une écriture dimensionnée par rapport à la map du programme appelé, contre le plus petit tampon de l'appelant. Les objets de tas adjacents (par exemple un struct bpf_array pulvérisé dans le même slab/ordre) peuvent être corrompus.
• Disponibilité. Une écriture mal ciblée est un oops / panic du noyau direct.
• Privilège. Sur un noyau non corrigé où des programmes BPF de cgroup peuvent être chargés, cette classe de dépassement de tas hors limites a été utilisée comme primitive d'élévation de privilèges locale (écrasement de map->ops, détournement d'un helper, commit_creds / changement d'espace de noms). C'est pourquoi cette arborescence étiquette le problème comme LPE. Le score plus faible de Red Hat reflète leur évaluation spécifique au produit, et non l'absence du bug.

Le bug ne nécessite pas de service exposé au réseau. Il est local. Il ne nécessite pas de TTY, d'helper setuid, ni d'interaction utilisateur.

Cause racine

Vérificateur vs exécution

Deux programmes BPF de cgroup, chacun avec son propre BPF_MAP_TYPE_CGROUP_STORAGE (variante partagée, BPF_CGROUP_STORAGE_SHARED) :

Le vérificateur vérifie A par rapport à la map de A et B par rapport à la map de B. Les deux passent.

À l'exécution, le helper fait :

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 est l'entrée de tableau du programme qui a démarré l'exécution du cgroup, et non du programme en cours d'exécution après bpf_tail_call. B opère donc sur l'objet de stockage de A.

Pourquoi les tailles importent

bpf_cgroup_storage_alloc() dimensionne le tampon sous-jacent à partir du value_size de la map. Le tampon de A est trop petit pour les accès vérifiés de B. Le résultat est une confusion de type de l'identité de la map à travers un transfert de contrôle — la même famille de bugs que les autres problèmes BPF où « le helper voit une map différente de celle vue par le vérificateur ».

Stockage partagé sur un cgroup

Le commit 7d9c342 a rendu les stockages de cgroup partagés entre les programmes attachés au même cgroup. Ce partage est ce qui fait de l'emplacement du contexte d'exécution un pointeur unique plutôt qu'une recherche par programme, et c'est pourquoi les noyaux antérieurs à 5.9 ne sont pas affectés.

Objets adjacents

BPF_PROG_TEST_RUN sur un programme BPF_PROG_TYPE_CGROUP_SKB alloue un stockage de cgroup pour la durée du test. Cette allocation se trouve sur le tas du noyau à côté de tout ce qui a été récemment libéré dans la même classe de taille — y compris les maps struct bpf_array dont le value_size a été choisi pour atterrir dans le même ordre kmalloc. Un dépassement hors limites depuis le tampon de stockage peut donc atteindre les champs bpf_map (ops, liste RCU, value[]) d'une map de tableau voisine.

Ce détail de disposition du tas est pourquoi un avis de « simple lecture hors limites » et une analyse LPE peuvent décrire le même CVE.

Versions du noyau affectées

Introduit : Linux 5.9 (7d9c3427894fe70d1347b4820476bf37736d2ff0)
Non affectés : tous les noyaux antérieurs à 5.9

En une ligne :

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

Encore ouvert dans certains stables : le tracker de noyau de Debian listait 5.10 upstream-stable / bullseye 5.10 comme needed. Ne présumez pas que chaque 5.10.y est corrigé.

Les numéros ABI des distributions mentent. Ubuntu 5.15.0-163 est un 5.15 corrigé même si 5.15.0 semble plus ancien que l'amont 5.15.192. Comparez le changelog du paquet / USN / DSA / ALAS / RHSA, et non uname -r par rapport au tableau ci-dessus.

Statut de distribution

Toute distribution ayant livré un noyau dans les plages ci-dessus était dans le périmètre jusqu'à ce qu'elle rétroporte abad3d0 (ou le commit stable correspondant). Il s'agit de code BPF générique, et non d'un correctif spécifique à une distribution.

Généralement affectées jusqu'à correction

Non affectées (noyau GA antérieur à 5.9)

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

Versions de paquets corrigées connues (exemples)

Ubuntu 26.04 / 25.10 sont listés non affectés (ils ont divergé après le correctif). Ubuntu 25.04 a atteint sa fin de vie encore needed.

Préconditions

Un hôte peut correspondre à une version affectée et rester néanmoins non atteignable. Vérifications utiles :

unprivileged_bpf_disabled=1 n'est pas un correctif complet — un utilisateur disposant de la capacité BPF peut toujours déclencher le bug — mais cela supprime le chemin non privilégié.

Le correctif

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

struct bpf_map_owner gagne un tableau storage_cookie[]. Lors de la mise à jour de la cible d'un tail call, le noyau désormais :

1. Si le programme appelé utilise bpf_get_local_storage() — exige que les maps de stockage de cgroup du programme appelé soient exactement celles de l'appelant (mêmes cookies).
2. Si le programme appelé n'utilise aucun stockage local de cgroup — autorise la combinaison de tail call.

Des tailles de valeur incompatibles ne peuvent plus être composées dans le dos du vérificateur. Chaque programme est toujours vérifié seul ; la nouvelle vérification porte sur l'arête entre eux.

Ne cherry-pickez pas le commit sur une arborescence arbitraire sans les helpers environnants de propriétaire/cookie BPF. Utilisez le rétroportage stable pour votre série.

Vérification d'un système en cours d'exécution

uname -r
# Comparez par rapport au tableau ci-dessus, puis par rapport à l'avis de votre distribution —
# les numéros ABI Ubuntu/Debian ne sont pas les numéros stables amont.

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 non privilégié autorisé (exposition la plus large)
# 1  = désactivé après la première utilisation privilégiée, ou entièrement désactivé selon le noyau
# 2  = désactivé (l'administrateur peut le réactiver)

Confirmez le paquet, pas seulement la chaîne de version :

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

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

Un noyau ≥ 6.17, ou un stable listé dans la colonne « première correction », ou un paquet de distribution issu du tableau des avis, constitue la véritable clôture.

Atténuation

1. Corrigez. Installez le noyau de distribution qui contient abad3d0 / l'équivalent stable. C'est le seul correctif complet.
2. En attendant de pouvoir corriger :
   • Définissez kernel.unprivileged_bpf_disabled=1 (ou 2) pour supprimer les chargeurs non privilégiés.
   • Restreignez CAP_BPF, CAP_PERFMON et CAP_SYS_ADMIN pour les utilisateurs et conteneurs non fiables.
   • Dans les espaces de noms utilisateur / conteneurs non privilégiés, désactivez BPF (seccomp, LSM, ou en retirant ces capacités dans le runtime).
3. Ne considérez pas « nous n'attachons pas nous-mêmes de programmes cgroup SKB » comme une sécurité. BPF_PROG_TEST_RUN suffit à exercer le chemin d'allocation ; un attaquant local fournit les programmes.

Organisation du dépôt

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

Ce répertoire documente la vulnérabilité et contient l'arborescence de recherche correspondante. Ce n'est pas un kit d'exploitation prêt à l'emploi : les symboles de gadgets du noyau (ARRAY_MAP_OPS_OFF, COMMIT_CREDS, …) sont des entrées à la compilation pour un vmlinux spécifique, et exécuter le programme contre un noyau en production sort du périmètre de ce README.

Références

CVE / NVD

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

Amont

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

Rétroportages stables

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

Distributions

• Page CVE Ubuntu
• Tracker de sécurité Debian
• Debian kernel-sec
• Red Hat
• Amazon Linux ALAS
• SUSE

Contact

Abraxas Labs — recherche / tests autorisés uniquement

Avertissement

Ce dépôt est destiné à la recherche et à l'éducation.

Ne compilez, n'exécutez, ne déployez et n'utilisez pas autrement le code présent ici contre un système quelconque sans autorisation écrite explicite à la fois de la partie hébergeant ce dépôt et du propriétaire de la cible. L'accès non autorisé à des systèmes informatiques est un crime.

Les auteurs et Abraxas Labs fournissent ce matériel tel quel, sans garantie qu'il soit complet, correct ou sûr à exécuter. La recherche sur l'exploitation du noyau peut provoquer un panic de la machine, corrompre des systèmes de fichiers et entraîner une perte de données. Vous assumez ce risque.

Trouvé dans la nature.