Katalog podatności CVE

Gitea rozwiązywało principala certyfikatu SSH, przeszukując zawartość wszystkich przechowywanych kluczy publicznych zamiast tylko kluczy principal. Gdy Gitea ufa certyfikatowi użytkownika (SSH_TRUSTED_USER_CA_KEYS) i akceptuje dowolne principaly (SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything), użytkownik mógł zarejestrować linię klucza publicznego innego użytkownika jako swój principal lub posiadacz certyfikatu podpisanego przez ten urząd mógł go wylistować, a następnie uwierzytelnić się jako właściciel tego klucza przez API podpisu HTTP i wbudowany serwer SSH. Instancje nieufające certyfikatowi użytkownika nie są dotknięte.

Handlery sieciowe Gitea do dodawania i usuwania reakcji na zgłoszeniach i komentarzach nie odrzucały zablokowanych zgłoszeń dla użytkowników bez uprawnień do zapisu, choć API to robiło. Zalogowany użytkownik mogący czytać zgłoszenie mógł więc dodawać lub usuwać reakcje na zablokowanym zgłoszeniu i jego komentarzach, omijając ograniczenie interakcji wynikające z blokady. Dotyczyło to tylko reakcji; żadna treść nie mogła zostać zmieniona.

POST /{owner}/{repo}/topics zostało zarejestrowane bez middleware logowania zapewniającego ochronę przed żądaniami cross-origin, więc żądanie wysłane przez witrynę trzeciej strony nie było odrzucane. Administrator repozytorium, który odwiedził złośliwą stronę, mógł mieć zmienione tematy swojego repozytorium. Żadne inne ustawienia repozytorium nie były osiągalne przez tę trasę.

Handlery artefaktów Gitea Actions v4 (Twirp) wczytywały całe ciało żądania do pamięci bez limitu rozmiaru. Użytkownik mogący uruchomić workflow i uzyskać token runnera tego uruchomienia mógł wysłać zbyt duże żądanie do usługi artefaktów i wyczerpać pamięć serwera, co kończy proces Gitea. Ciało żądania jest teraz ograniczone do 1 MiB.

Żądanie /{username}/-/repositories dla użytkownika indywidualnego zamiast organizacji powodowało, że handler strony głównej organizacji dereferencjonował nil organizację i panikował. Żądanie nie wymaga uwierzytelnienia ani specjalnej konfiguracji. Serwer odpowiadał błędem HTTP 500 i logował panikę dla każdego żądania; poprawka zwraca 404 dla użytkowników indywidualnych.

Callback powiązania OpenID w ustawieniach bezpieczeństwa Gitea akceptował pozytywną asercję OpenID 2.0 bez sprawdzenia, czy zalogowany użytkownik rozpoczął proces łączenia. Ponieważ OpenID 2.0 pozwala na asercje nieżądane, kontrolowany przez atakującego dostawca OpenID mógł przypiąć tożsamość atakującego do konta zalogowanej ofiary, która otworzyła spreparowany link, a następnie atakujący mógł zalogować się jako ofiara przez OpenID, co nie stosuje lokalnych kontroli TOTP ani WebAuthn. Callback wymaga teraz ograniczonego czasowo parametru `state` powiązanego z użytkownikiem.

Konsola zarządzania nieprawidłowo waliduje dane wejściowe związane z konfiguracją magazynów użytkowników JDBC. Słabość ta pozwala atakującemu dostarczyć specjalnie spreparowane dane wejściowe, które mogą prowadzić do wykonania dowolnego kodu na dotkniętym serwerze. Skuteczne wykorzystanie umożliwia atakującemu wykonanie dowolnego kodu z uprawnieniami produktu WSO2, co może doprowadzić do pełnego przejęcia systemu.

W Soarkey StudentManagement do wersji e08f7f1d5015af407aa4cca0ada3dea189b4937e wykryto podatność w funkcji UserDao.login w pliku code/src/service/AdminDao.java. Manipulacja argumentem Password powoduje przechowywanie danych wrażliwych w postaci jawnej. Atak wymaga lokalnego dostępu, a exploit został publicznie ujawniony i może być wykorzystany. Projekt został poinformowany o problemie, ale nie odpowiedział.

Wykryto podatność w itsmeravitejak Online-Examination-System do wersji e6208e630b14657999bbfe4c9912302d2a1e2449. Problem dotyczy funkcji Exam::startExam w pliku exam.php w module Exam Module, gdzie manipulacja argumentem topicid prowadzi do wstrzyknięcia SQL. Atak można przeprowadzić zdalnie, a exploit jest publicznie dostępny.

W jądrze Linux rozwiązano podatność w module dm-pcache: odrzucanie ksetu przekraczającego swój segment. Funkcje cache_replay(), worker zapisu zwrotnego i worker GC odczytują kset o rozmiarze get_kset_onmedia_size() bajtów i przesuwają pozycję o tę wartość. Sfałszowany key_num powoduje, że rozmiar przekracza pozostałe miejsce w segmencie, przez co przesunięcie wychodzi poza segment i wyzwala BUG_ON w cache_pos_advance().

W jądrze Linux rozwiązano podatność w module dm-pcache: ograniczenie logicznego przesunięcia klucza z pamięci trwałej. Funkcja cache_key_decode() pobiera logiczne przesunięcie klucza z urządzenia pamięci podręcznej i później indeksuje req_key_tree->subtrees[] za jego pomocą w get_subtree(). Przesunięcie poza urządzenie tworzy wskaźnik poddrzewa poza tablicą, do którego rb_insert() zapisuje podczas odtwarzania.

W jądrze Linux rozwiązano podatność w module sched/cache: wprowadzono task_struct->sched_cache_grp w celu naprawy use-after-free. Dodano wskaźnik sched_cache_grp do task_struct, aby kod schedulera mógł uzyskać dostęp do grupy cache bezpośrednio przez zadanie, bez pośrednictwa mm->sched_cache_grp. Każde zadanie utrzymuje własny licznik referencji na sched_cache_group, niezależny od referencji w mm_struct. Referencja jest pozyskiwana w copy_mm() (fork) i exec_mmap() (exec), a zwalniana w exit_mm(). Naprawia to use-after-free, gdy account_mm_sched() dociera do grupy przez zadanie, którego mm jest przełączane.

W jądrze Linux w schedulerze sched_ext funkcja ops.dequeue() była wywoływana z wciąż trzymaną blokadą DSQ na ścieżkach consume i move. Jeśli scheduler BPF próbował zablokować źródłowy DSQ wewnątrz ops.dequeue(), dochodziło do samozakleszczenia. Poprawka przenosi wywołanie po zwolnieniu blokady DSQ na wszystkich trzech ścieżkach.

W jądrze Linux w sched_ext zadanie mogło znajdować się na DSQ, gdy jego stan wciąż był SCX_OPSS_DISPATCHING. Ścieżki reenqueue nie czekały na wyczyszczenie tego stanu, więc ops.enqueue() ustawiał SCX_OPSS_QUEUED, a następnie końcowy zapis dyspozytora nadpisywał go wartością SCX_OPSS_NONE, powodując porzucenie kolejnych dispatchy zadania. Poprawka czeka na wyczyszczenie SCX_OPSS_DISPATCHING przed dequeue do reenqueue.

W KVM na architekturze x86 żądanie GET_NESTED_STATE_PAGES nie było ponownie ustawiane, gdy pobranie stron zagnieżdżonych kończyło się niepowodzeniem w ścieżce KVM_RUN. Jeśli użytkownik ponownie uruchomił vCPU, a vmcs02 zawierał ważne PFN z poprzedniego uruchomienia L2, KVM mógł wejść do L2 ze starymi, nieprzypiętymi PFN zmapowanymi np. na stronę vAPIC.

W podsystemie audit jądra Linux funkcja kill_rules() usuwała reguły AUDIT_DIR i AUDIT_EXE podczas przycinania drzewa audytu, zwalniając entry->rule.exe przed usunięciem reguły z list widocznych przez RCU. Usunięcie obserwowanego katalogu mogło wyścignąć się z innym zadaniem oceniającym regułę, powodując use-after-free w audit_mark_compare().

W jądrze Linux naprawiono podatność w mechanizmie fprobe, polegającą na tym, że funkcje wyrejestrowujące fprobe (unregister_fprobe, unregister_fprobe_async) opierały się na standardowych okresach łaski RCU, które nie śledzą sekcji z wyłączonym wywłaszczaniem, gdy RCU nie obserwuje (np. w pętli bezczynności lub w stanach nohz_full). Mogło to prowadzić do użycia zwolnionej pamięci (use-after-free), jeśli fprobe został zwolniony zaraz po wyrejestrowaniu. Poprawka zapewnia wczesne wyjście z procedur obsługi, gdy !rcu_is_watching(), oraz zastępuje guard(rcu)() i rcu_read_lock() przez guard(rcu_sched_notrace)(), co eliminuje narzut lockdep na szybkiej ścieżce.

W podsystemie HID BPF jądra Linux porównanie zwracanej wartości z hid_bpf_hw_request z rozmiarem nie rzutowało rozmiaru na ssize_t. Gdy sterownik transportu zwracał ujemny kod błędu (np. -EPIPE), był on promowany do size_t i oceniany jako duża liczba dodatnia, przez co warunek (ret > size) stawał się prawdziwy. Powodowało to ciche potraktowanie błędu sprzętowego jako sukcesu i skopiowanie niezmodyfikowanego bufora.

W jądrze Linux w sterowniku HID multitouch funkcja mt_remove() używała timer_delete_sync() do zatrzymania timera odpowiedzialnego za tzw. sticky fingers. Timer mógł jednak zostać ponownie uzbrojony przez raport przychodzący po jego usunięciu, co prowadziło do użycia zwolnionej pamięci (use-after-free) po odłączeniu sterownika. Problem rozwiązano, zastępując timer_delete_sync() funkcją timer_shutdown_sync(), która dodatkowo blokuje późniejsze mod_timer().

W io_uring jądra Linux w trybie SQPOLL wątek sqpoll mógł pobrać i ukończyć żądanie zaraz po opublikowaniu go przez mpscq_push(). Jeśli było to ostatnie żądanie utrzymujące pierścień przy życiu, io_ring_exit_work() zwalniało ctx, zatrzymywało wątek i tctx, podczas gdy io_req_normal_work_add() wciąż odwoływało się do nich, powodując use-after-free. Poprawka utrzymuje blokadę RCU wokół dodawania i czeka na okres karencji przed zwolnieniem ctx.