CVE-2025-38502
WysokieCVSS 7.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 6 - wyżej niż 6% wszystkich znanych CVE
Streszczenie
W jądrze systemu Linux zidentyfikowano podatność polegającą na dostępie poza granice w lokalnym magazynie cgroup, która może być wykorzystana poprzez wywołania tail call. Problem występuje, gdy dwa programy korzystają z lokalnego magazynu cgroup o różnych rozmiarach wartości, co prowadzi do niezamierzonego dostępu poza granice.
Ocena ryzyka
Wykorzystanie tej podatności może prowadzić do nieprzewidzianych zachowań systemu, w tym potencjalnego naruszenia integralności danych lub awarii aplikacji. Organizacje powinny być świadome ryzyka związanego z nieprawidłowym zarządzaniem pamięcią w kontekście programów BPF.
Rekomendacja
Zaleca się aktualizację jądra systemu Linux do najnowszej wersji, która zawiera poprawkę dla tej podatności. Dodatkowo, administratorzy powinni monitorować użycie lokalnego magazynu cgroup w swoich aplikacjach BPF.
Powiązane podatności
- CVE-2026-96759Krytyczne
orval przed wersją 8.29.0 nie escapuje parametru operationId podczas emitowania go do wygenerowanych obiektów metadanych opcji mutatorów TanStack Query. Atakujący mogą wstrzyknąć dowolny kod JavaScript poprzez spreparowany operationId w specyfikacji OpenAPI, który wykonuje się podczas wywoływania wygenerowanych hooków.
- CVE-2026-96758Krytyczne
orval @orval/core przed wersją 8.28.0 zawiera podatność na wstrzyknięcie kodu w serializerze form-data, który nie escapuje nazw właściwości multipart w wygenerowanych literałach szablonów. Atakujący mogą wstrzyknąć wyrażenia ${...} do nazw właściwości schematu OpenAPI, które wykonują się jako żywa interpolacja podczas budowania przez wygenerowany klient treści FormData z uprawnieniami procesu konsumenta.
- CVE-2026-96757Krytyczne
orval przed wersją 8.29.0 nie escapuje kluczy typów mediów OpenAPI podczas emitowania ich do literałów łańcuchowych Content-Type w pojedynczych cudzysłowach w wygenerowanym kodzie. Atakujący mogą wstrzyknąć JavaScript poprzez spreparowane klucze typów mediów w specyfikacjach OpenAPI, który wykonuje się podczas wywoływania wygenerowanych operacji fetch lub resolverów mock.
- CVE-2026-96755Krytyczne
orval w wersjach od 8.14.0 do 8.28.1 zawiera podatność na wstrzyknięcie kodu w generatorze @orval/effect, który konwertuje domyślne wartości schematu OpenAPI na literały szablonów. Atakujący mogą wstrzyknąć dowolne wyrażenia JavaScript poprzez domyślne wartości schematu zawierające składnię ${...}, które są wykonywane w zakresie modułu podczas budowania lub importowania wygenerowanego kodu.
- CVE-2026-96754Krytyczne
orval w wersjach przed 8.29.0 zawiera podatność na wstrzyknięcie kodu w generatorze @orval/hono, który nie escapuje wartości ścieżek OpenAPI w literałach tras w pojedynczych cudzysłowach. Atakujący mogą spreparować dokument OpenAPI z apostrofem w statycznym segmencie ścieżki, aby wstrzyknąć dowolny kod JavaScript, który wykonuje się podczas importowania wygenerowanego modułu TypeScript.
- CVE-2026-95848Krytyczne
Moquette to lekki broker MQTT napisany w Javie. Przed wersją 0.18.1, gdy skonfigurowana klasa uwierzytelniająca lub autoryzująca nie może zostać załadowana, Server.initializeAuthenticator i Server.initializeAuthorizatorPolicy traktują błąd tak, jakby nie skonfigurowano żadnej klasy niestandardowej i wracają do AcceptAllAuthenticator lub PermitAllAuthorizatorPolicy. Błędnie napisana nazwa klasy, brakująca zależność, błąd konstruktora lub problem ze ścieżką klas może zatem uruchomić brokera z wyłączonym uwierzytelnianiem lub autoryzacją, nawet jeśli operator skonfigurował te zabezpieczenia. Problem został naprawiony w wersji 0.18.1.
- CVE-2026-85724Krytyczne
Moquette to lekki broker MQTT w Javie. Przed wersją 0.18.1, gdy skonfigurowano reguły ACL oparte na wzorcach, AuthorizationsCollector.canDoOperation podstawia identyfikator klienta i nazwę użytkownika bezpośrednio do reguł zawierających %c lub %u, a następnie traktuje wynik jako filtr tematu MQTT. Klient używający + lub # w którejkolwiek z tych wartości może rozszerzyć podstawiony filtr i uzyskać dostęp do odczytu i zapisu między dzierżawami. Tożsamość z # może również wygenerować nieprawidłowy filtr, który powoduje wyjątek NullPointerException w Topic.match i zakłóca przetwarzanie sesji. Problem został naprawiony w wersji 0.18.1.
- CVE-2025-63564Krytyczne
Podatność na wstrzyknięcie SQL w pluginie Socialwall dla Moodle w wersjach od 3.0 do 3.3 pozwala atakującemu na wykonanie dowolnego kodu za pomocą spreparowanych żądań HTTP.
- CVE-2026-18872Krytyczne
IBM Financial Transaction Manager (FTM) dla RedHat OpenShift jest podatny na trwały cross-site scripting (CWE-79) w komponencie React NetworkAcknowledgement (NetworkAcknowledgement.jsx:42). Złośliwy aktor może wstrzyknąć skrypt do przechowywanych danych potwierdzenia sieciowego, który wykonuje się w przeglądarkach uwierzytelnionych operatorów, umożliwiając przejęcie sesji i nieautoryzowane działania płatnicze na poziomie operatora.
- CVE-2026-96276Krytyczne
Jeśli złośliwy kontener SDK deklaruje punkt rozszerzenia z spreparowaną ścieżką `directory`, a programista uruchomi `flatpak build-init --writable-sdk --sdk-extension` z tym SDK, pliki wybrane przez atakującego mogą zostać zapisane poza katalogiem roboczym, ponieważ ścieżka docelowa jest rozwiązywana przez funkcję, która pozwala na przejście `..`.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix oob access in cgroup local storage Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context: 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); For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access. To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.