Katalog podatności CVE

Problem w Wellav WES Emergency Broadcast Terminal WES100, WES270, WES280 i WES290 przed 08-08-2023 pozwala zdalnemu atakującemu na uzyskanie poufnych informacji poprzez globalną funkcję opakowującą żądania API.

Problem w sterowniku magazynu danych VMware w OpenStack glance_store. Gdy uwierzytelniony atakujący poda złośliwie spreparowany URI lokalizacji obrazu wskazujący na zewnętrzny serwer, funkcja _retry_request nie weryfikuje hosta docelowego przed dołączeniem poufnych nagłówków uwierzytelniających.

W API Image (v2) w OpenStack Glance występuje podatność typu Server-Side Request Forgery (SSRF). Gdy opcja show_multiple_locations jest włączona w glance-api.conf, uwierzytelniony atakujący może manipulować atrybutem locations obrazu w stanie queued, wysyłając spreparowane żądanie HTTP PATCH.

D-Link DAP-2610 do wersji 2.06B08r099 zawiera podatność na wstrzyknięcie poleceń w interfejsie webowym w punkcie końcowym /index.xgi. Atakujący z uwierzytelnionym dostępem może wykorzystać niektóre parametry do wykonania dowolnych poleceń systemowych.

Ten identyfikator CVE został odrzucony. Jest duplikatem rezerwacji CVE-2026-62062. Wszystkie odwołania i opisy zostały usunięte, aby zapobiec przypadkowemu użyciu.

W jądrze Linux w sterowniku wifi mt76 (mt7921) występuje luka polegająca na braku walidacji rekordów firmware CLC. Loader ufa liczbie regionów i długości każdego rekordu, przez co zniekształcony obraz firmware może spowodować, że wskaźnik tablicy regionów wyprzedzi bufor firmware, pętla rekordów nie będzie się przesuwać lub indeks phy->clc wyjdzie poza zakres.

W jądrze Linux podatność w ppp_async polega na tym, że ścieżka obsługi błędnej ramki zeruje headroom bufora skb, łamiąc gwarancję NET_SKB_PAD. W efekcie kolejna ramka może zostać przetworzona bez wymaganego zapasu, co prowadzi do paniki jądra (skb_under_panic) lub odczytu poza granicami bufora przy kompresji CCP.

W jądrze Linux w podsystemie EDAC/device_sysfs plik sysfs poll_msec używa simple_strtoul(), która przyjmuje unsigned long, podczas gdy docelowe pole poll_msec jest typu unsigned int. W systemach 64-bitowych wartość większa niż UINT_MAX jest po cichu obcinana przy zapisie.

W jądrze Linux sterownik drm/virtio (virtio-gpu) na domenach Xen PV błędnie decyduje o użyciu DMA API, patrząc tylko na bit VIRTIO_F_ACCESS_PLATFORM. Ponieważ QEMU domyślnie nie ustawia iommu_platform dla virtio-vga, funkcja virtio_gpu_object_shmem_init() opisuje strony bufora ramki hostowi za pomocą sg_phys() używając adresów fizycznych gościa, które w domenie PV wskazują na strony należące do innej domeny.

W jądrze Linux w sterowniku accel/qaic funkcja resp_worker() pomija sprawdzanie granic obecne w decode_message(), co może prowadzić do odczytu poza końcem alokacji slab, nieskończonych pętli lub paniki jądra. Do wystąpienia problemu konieczne jest wysłanie zniekształconej wiadomości z urządzenia.

W jądrze Linux w sterowniku nvme-rdma ścieżka queue_rq przy błędzie -EIO zgłasza błąd ścieżki hosta, a następnie nadal wykonuje czyszczenie polecenia i odmapowuje DMA SQE. Ponieważ pomocnik błędu ścieżki kończy żądanie, dochodzi do podwójnego czyszczenia i odmapowania DMA po zakończeniu żądania.

W jądrze Linux funkcja nvme_query_fdp_info() jest wywoływana dla każdej ścieżki i wypełnia head->nr_plids/head->plids na potrzeby rejestracji FDP, ale nic nie chroni tej pary przed równoczesnym dostępem. Dwie ścieżki skanujące tę samą przestrzeń nazw mogą wywołać wyścig podczas wypełniania tych danych.

W jądrze Linux w module nvmet-rdma występuje wyciek zasobów. Gdy liczba oczekujących kolejek do rozłączenia przekracza limit backlogu, ścieżka połączenia zwalnia jedynie referencję do urządzenia, ale nie zwalnia nowo przydzielonej kolejki ani jej zasobów IB.

W jądrze Linux występuje błąd w weryfikatorze BPF dotyczący arytmetyki na wskaźnikach w ścieżce spekulatywnej. Podczas przetwarzania operacji dodawania do wskaźnika (r0 += r1) stan rejestru jest migawkowany w momencie, gdy pole var_off i zakres 32-bitowy są niespójne, co prowadzi do naruszenia niezmienników rejestru i ostrzeżenia weryfikatora. Problem dotyczy programów nieuprzywilejowanych i został naprawiony poprzez przeniesienie wywołania __mark_reg32_unbounded() za funkcję sanitize_ptr_alu().

W jądrze Linux w podsystemie BPF funkcja bpf_map_check_op_flags() porównuje identyfikator CPU z num_possible_cpus() zamiast z nr_cpu_ids i cpu_possible(). Przy rzadkich identyfikatorach CPU (np. maska 0,2-3) nieprawidłowy CPU 1 jest akceptowany, a prawidłowy CPU 3 odrzucany, co prowadzi do błędu strony jądra i paniki.

W jądrze Linux w podsystemie BPF ścieżki aktualizacji map per-CPU (array, hash, cgroup storage) bez BPF_F_CPU lub BPF_F_ALL_CPUS używają logicznego identyfikatora CPU do obliczenia przesunięcia w buforze, zamiast gęstego przesunięcia. Przy rzadkich identyfikatorach CPU (np. maska 0,2-3) powoduje to nieprawidłowe wartości per-CPU oraz odczyt poza zakresem bufora dla CPU3.

W jądrze Linux w sterowniku drm/gud nie jest weryfikowane, czy flaga GUD_ROTATION_0 znajduje się w maskach obsługiwanych rotacji urządzenia. Urządzenie, które pomija ten bit w GUD_PROPERTY_ROTATION, wywołuje WARN_ON w drm_plane_create_rotation_property().

W jądrze Linux w podsystemie printk użycie WARN_ON() do wykrywania niepowodzenia kthread_run() jest nieprawidłowe, ponieważ __kthread_create_on_node() zwraca -EINTR po otrzymaniu SIGKILL. Powoduje to fałszywe ostrzeżenia jądra w normalnych warunkach.

W jądrze Linux w sterowniku accel/amdxdna struktura amdxdna_cmd_chain zawiera elastyczną tablicę z adnotacją __counted_by(command_count). Ponieważ struktura jest przechowywana w pamięci współdzielonej AMDXDNA_BO_SHARE, przestrzeń użytkownika może równolegle zmienić command_count na zero, co powoduje niepowodzenie sprawdzania zakresu i panikę jądra.

W jądrze Linux w sterowniku accel/amdxdna łańcuch poleceń z command_count równym zero przechodzi sprawdzanie długości ładunku, a pętla wypełniania się nie wykonuje. Na firmware bez AIE2_NPU_COMMAND żądanie jest odrzucane, ale na firmware z aie2_get_npu_chain_msg_op() trafia do drm_clflush_virt_range(cmd_buf, 0), co powoduje odczyt bajtu przed buforem i błąd na stronie ochronnej vmap.