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

CVE-2025-38502

Linux-Kernel-BPF-Cgroup-Local-Storage-Out-of-Bounds-Zugriff über Tail Calls

Nur für Forschung / Bildungszwecke. Führen Sie Material in diesem Repository nicht aus, setzen Sie es nicht ein und verwenden Sie es nicht gegen einen Host, es sei denn, Sie haben die ausdrückliche schriftliche Genehmigung sowohl der Partei, die dieses Repository hostet, als auch des Eigentümers der Zielsysteme. In freier Wildbahn gefunden.

Der Quelldateiname CVE-2025-3850-Linux-LPE-Abaraxas-Labs.c schneidet den Bezeichner ab. Der veröffentlichte Eintrag ist CVE-2025-38502. Es gibt kein Linux-CVE CVE-2025-3850.

Inhalt

• Zusammenfassung
• Auswirkung
• Ursache
• Betroffene Kernel-Versionen
• Distributionsstatus
• Voraussetzungen
• Der Fix
• Überprüfung eines laufenden Systems
• Mitigation
• Repository-Struktur
• Referenzen
• Kontakt
• Haftungsausschluss

Zusammenfassung

Lonial meldete, dass Cgroup-BPF-Local-Storage über einen Tail Call hinweg außerhalb der Grenzen zugegriffen werden kann.

Der eBPF-Verifier prüft jedes Programm isoliert auf Typen. Zur Laufzeit sucht bpf_get_local_storage() nicht die Map des aktuell ausgeführten Programms. Es liest den Cgroup-Storage-Zeiger aus current->bpf_ctx → bpf_cg_run_ctx → prog_item->cgroup_storage[]. Dieser Slot wird vom ursprünglich angehängten Programm befüllt, nicht von dem Programm, in das per Tail Call gesprungen wurde.

Wenn Programm A (kleine BPF_MAP_TYPE_CGROUP_STORAGE-Wertgröße) per Tail Call in Programm B (große Wertgröße) springt, liefert bpf_get_local_storage() von B weiterhin den kleineren Puffer von A. Zugriffe, die der Verifier gegen B's Map erlaubt hat, laufen dann über das Ende von A's Allokation hinaus.

Der Defekt wurde in Linux 5.9 durch 7d9c342 (bpf: Make cgroup storages shared between programs on the same cgroup) eingeführt. Behoben wurde er durch Erweiterung von bpf_map_owner um ein storage_cookie[], sodass Tail-Call-Kombinationen nur akzeptiert werden, wenn der Callee dieselben Cgroup-Storage-Maps wie der Caller verwendet oder gar keine.

Auswirkung

Dies ist ein lokaler Kernel-Heap-Out-of-Bounds-Zugriff. Die Schweregradbewertung variiert je nach Hersteller, weil sie sich uneinig darüber sind, ob das Primitiv ein „Read-only-DoS“ oder vollständige Speicherbeschädigung ist:

Was das in der Praxis bedeutet:

• Vertraulichkeit. Ein OOB-Read des benachbarten kmalloc-Objekts kann Kernel-Zeiger (KASLR-Slide), Heap-Cookies und Inhalte angrenzender Strukturen preisgeben.
• Integrität. Dieselbe Fehlanpassung ist ein größenbasierter Schreibzugriff relativ zur Map des Callee gegen den kleineren Puffer des Caller. Benachbarte Heap-Objekte (zum Beispiel ein in dieselbe Slab/Order gespraytes struct bpf_array) können beschädigt werden.
• Verfügbarkeit. Ein fehlgeleiteter Schreibzugriff ist ein unkomplizierter Kernel-Oops / Panic.
• Privilegien. Auf einem ungepatchten Kernel, auf dem BPF-Cgroup-Programme geladen werden können, wurde diese Klasse von Heap-OOB als Primitiv für lokale Privilegieneskalation verwendet (Überschreiben von map->ops, Hijacking eines Helpers, commit_creds / Namespace-Wechsel). Deshalb bezeichnet dieser Tree das Problem als LPE. Red Hats niedrigerer Score spiegelt deren produktspezifische Bewertung wider, nicht die Abwesenheit des Bugs.

Der Bug erfordert keinen netzwerkseitig erreichbaren Dienst. Er ist lokal. Er erfordert kein TTY, keinen setuid-Helper und keine Benutzerinteraktion.

Ursache

Verifier vs. Laufzeit

Zwei Cgroup-BPF-Programme, jedes mit eigenem BPF_MAP_TYPE_CGROUP_STORAGE (Shared-Flavor, BPF_CGROUP_STORAGE_SHARED):

Der Verifier prüft A gegen A's Map und B gegen B's Map. Beide bestehen.

Zur Laufzeit macht der Helper Folgendes:

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 ist der Array-Eintrag für das Programm, das den Cgroup-Run gestartet hat, nicht für das Programm, das nach bpf_tail_call aktuell ausgeführt wird. B arbeitet daher auf A's Storage-Objekt.

Warum die Größen wichtig sind

bpf_cgroup_storage_alloc() dimensioniert den zugrunde liegenden Puffer anhand der value_size der Map. A's Puffer ist zu klein für B's verifizierte Zugriffe. Das Ergebnis ist eine klassische Typverwechslung der Map-Identität über einen Kontrolltransfer hinweg — dieselbe Bug-Familie wie andere BPF-Probleme, bei denen „der Helper eine andere Map sieht als der Verifier“.

Shared Storage auf einer Cgroup

Commit 7d9c342 machte Cgroup-Storages zwischen Programmen, die an dieselbe Cgroup angehängt sind, geteilt. Diese Teilung ist der Grund, warum der Run-Context-Slot ein einzelner Zeiger ist statt eines Lookups pro Programm, und warum Kernel vor 5.9 nicht betroffen sind.

Benachbarte Objekte

BPF_PROG_TEST_RUN auf einem BPF_PROG_TYPE_CGROUP_SKB-Programm allokiert Cgroup-Storage für die Dauer des Tests. Diese Allokation liegt auf dem Kernel-Heap neben allem anderen, was kürzlich in derselben Größenklasse freigegeben wurde — einschließlich struct bpf_array-Maps, deren value_size so gewählt wurde, dass sie in derselben kmalloc-Order landen. Ein OOB vom Storage-Puffer kann daher bpf_map-Felder (ops, RCU-Liste, value[]) einer benachbarten Array-Map erreichen.

Dieses Heap-Layout-Detail ist der Grund, warum ein „bloßes OOB-Read“-Advisory und ein LPE-Write-up dieselbe CVE beschreiben können.

Betroffene Kernel-Versionen

Eingeführt: Linux 5.9 (7d9c3427894fe70d1347b4820476bf37736d2ff0)
Nicht betroffen: alle Kernel vor 5.9

Einzeiler:

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

In einigen Stables noch offen: Debian's Kernel-Tracker listete 5.10 Upstream-Stable / bullseye 5.10 als needed. Gehen Sie nicht davon aus, dass jedes 5.10.y gepatcht ist.

Distro-ABI-Nummern täuschen. Ubuntu 5.15.0-163 ist ein gepatchter 5.15, obwohl 5.15.0 älter aussieht als Upstream 5.15.192. Vergleichen Sie das Paket-Changelog / USN / DSA / ALAS / RHSA, nicht uname -r mit der obigen Tabelle.

Distributionsstatus

Jede Distribution, die einen Kernel in den obigen Bereichen ausgeliefert hat, war im Rahmen, bis sie abad3d0 (oder den passenden Stable-Commit) zurückportiert hat. Dies ist generischer BPF-Code, kein distro-spezifischer Patch.

Typischerweise betroffen bis gepatcht

Nicht betroffen (GA-Kernel älter als 5.9)

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

Bekannte gepatchte Paketversionen (Beispiele)

Ubuntu 26.04 / 25.10 sind als nicht betroffen gelistet (sie zweigten nach dem Fix ab). Ubuntu 25.04 erreichte EOL weiterhin needed.

Voraussetzungen

Ein Host kann einer betroffenen Version entsprechen und dennoch nicht erreichbar sein. Nützliche Prüfungen:

unprivileged_bpf_disabled=1 ist kein vollständiger Fix — ein Benutzer mit BPF-Capability kann den Bug weiterhin auslösen — aber es entfernt den unprivilegierten Pfad.

Der Fix

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

struct bpf_map_owner erhält ein storage_cookie[]-Array. Beim Update des Tail-Call-Ziels macht der Kernel nun Folgendes:

1. Wenn der Callee bpf_get_local_storage() verwendet — verlange, dass die Cgroup-Storage-Maps des Callee exakt die Maps des Caller sind (gleiche Cookies).
2. Wenn der Callee keinen Cgroup Local Storage verwendet — erlaube die Tail-Call-Kombination.

Nicht übereinstimmende Wertgrößen können nicht mehr hinter dem Rücken des Verifiers kombiniert werden. Jedes Programm wird weiterhin allein verifiziert; die neue Prüfung liegt auf der Kante zwischen ihnen.

Cherry-picken Sie den Commit nicht auf einen beliebigen Tree ohne die umgebenden BPF-Owner/Cookie-Helper. Verwenden Sie den Stable-Backport für Ihre Serie.

Überprüfung eines laufenden Systems

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)

Bestätigen Sie das Paket, nicht nur den Versionsstring:

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

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

Ein Kernel ≥ 6.17, oder ein Stable aus der Spalte „Erstmals behoben“, oder ein Distro-Paket aus der Advisory-Tabelle, ist der tatsächliche Abschluss.

Mitigation

1. Patchen. Installieren Sie den Distro-Kernel, der abad3d0 / das Stable-Äquivalent enthält. Dies ist der einzige vollständige Fix.
2. Bis Sie patchen können:
   • Setzen Sie kernel.unprivileged_bpf_disabled=1 (oder 2), um unprivilegierte Loader auszuschließen.
   • Beschränken Sie CAP_BPF, CAP_PERFMON und CAP_SYS_ADMIN für nicht vertrauenswürdige Benutzer und Container.
   • In User-Namespaces / unprivilegierten Containern: Deaktivieren Sie BPF (seccomp, LSM oder Entfernen dieser Caps in der Runtime).
3. Betrachten Sie „wir hängen selbst keine Cgroup-SKB-Programme an“ nicht als Sicherheit. BPF_PROG_TEST_RUN reicht aus, um den Allokationspfad zu durchlaufen; ein lokaler Angreifer liefert die Programme.

Repository-Struktur

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

Dieses Verzeichnis dokumentiert die Schwachstelle und enthält den zugehörigen Forschungs-Tree. Es ist kein Drop-in-Exploit-Kit: Kernel-Gadget-Symbole (ARRAY_MAP_OPS_OFF, COMMIT_CREDS, …) sind Compile-Zeit-Eingaben für ein spezifisches vmlinux, und das Ausführen des Programms gegen einen laufenden Kernel liegt außerhalb des Rahmens dieses README.

Referenzen

CVE / NVD

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

Upstream

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

Stable-Backports

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

Distros

• Ubuntu CVE-Seite
• Debian Security Tracker
• Debian kernel-sec
• Red Hat
• Amazon Linux ALAS
• SUSE

Kontakt

Abraxas Labs — nur Forschung / autorisierte Tests

Haftungsausschluss

Dieses Repository dient Forschung und Bildung.

Kompilieren, führen Sie aus, setzen Sie ein oder verwenden Sie den Code hier anderweitig nicht gegen ein System, es sei denn, Sie haben die ausdrückliche schriftliche Genehmigung sowohl der Partei, die dieses Repository hostet, als auch des Eigentümers des Ziels. Unbefugter Zugriff auf Computersysteme ist eine Straftat.

Die Autoren und Abraxas Labs stellen dieses Material wie besehen bereit, ohne Gewährleistung, dass es vollständig, korrekt oder sicher auszuführen ist. Kernel-Exploitation-Forschung kann eine Maschine zum Absturz bringen, Dateisysteme beschädigen und Datenverlust verursachen. Sie übernehmen dieses Risiko.

In freier Wildbahn gefunden.