Katalog podatności CVE

W jądrze Linux w sterowniku qcom_battmgr funkcja qcom_battmgr_sc8280xp_strcpy() kopiuje ciągi znaków z firmware bez gwarancji terminatora, gdy firmware nie używa formatu Pascal. Pola model_number, serial_number i oem_info mogą nie być zakończone znakiem null, co powoduje odczyt poza granice bufora przy wyświetlaniu ich w przestrzeni użytkownika.

W jądrze Linux w sterowniku ładowarki rt9455 występuje błąd use-after-free. Podczas usuwania sterownika (rt9455_remove) kolejność anulowania zadań opóźnionych jest nieprawidłowa — batt_presence_work może zakolejkować max_charging_time_work po jego anulowaniu, co prowadzi do odwołania się do zwolnionej struktury rt9455_info. Problem występuje również w ścieżce błędu funkcji probe, gdy rt9455_hw_init() zawiedzie po zarejestrowaniu przerwania.

W jądrze Linux w sterowniku twl4030_charger występuje błąd use-after-free. Funkcja twl4030_bci_remove() nie anuluje dwóch workerów (bci->work i bci->current_worker), które odwołują się do struktury bci alokowanej przez devm, co może prowadzić do dostępu do zwolnionej pamięci po usunięciu urządzenia.

W jądrze Linux w sterowniku ucs1002 występuje błąd use-after-free podczas usuwania urządzenia. Sterownik nie ma funkcji remove, więc odłączenie odbywa się przez devm, ale devm zwalnia przerwanie alert IRQ bez anulowania opóźnionej pracy health_poll, która może następnie odwołać się do zwolnionej pamięci.

W jądrze Linux w sterowniku max17040 funkcje max17040_get_vcell() i max17040_get_soc() ignorują błędy zwracane przez regmap_read(). Gdy transfer I2C zawiedzie, niezainicjalizowana wartość rejestru jest konwertowana i raportowana do przestrzeni użytkownika jako prawidłowe napięcie lub stan naładowania, a worker może zastąpić buforowany stan naładowania błędną wartością.

W jądrze Linux w sterowniku max17040 występuje problem z synchronizacją anulowania pracy podczas suspend. Funkcja max17040_work() ponownie kolejkuje się po każdym odpytywaniu, a cancel_delayed_work() nie czeka na już uruchomiony callback, co może prowadzić do kontynuowania dostępu do układu paliwa po zakończeniu suspend.

W jądrze Linux na architekturze s390 podatność w podsystemie cpum_cf (licznik wydajności CPU) powoduje panikę jądra, gdy procesor jest włączany w trakcie działania polecenia perf stat. Struktura danych dla danego CPU nie jest inicjalizowana, jeśli CPU było offline w momencie tworzenia zdarzenia perf, co prowadzi do odwołania do wskaźnika NULL w funkcji cpumf_pmu_add().

W jądrze Linux na architekturze s390 makro MVIY_PERCPU() generuje wywołanie makra asemblera z argumentami łańcuchowymi rozdzielonymi spacjami, co w starszych wersjach binutils (przed 2.39) powoduje nieprawidłowe parsowanie i pominięcie instrukcji mviy. W rezultacie przerwana sekwencja per-CPU nie jest oznaczana w lowcore, a ścieżka powrotu z wyjątku nie może naprawić rejestru adresu per-CPU po migracji.

W jądrze Linux w sterowniku s390/dasd funkcja dasd_int_handler() oznaczała żądanie odczytu NRF nieprzydzielonego toru ESE jako zakończone sukcesem (DASD_CQR_SUCCESS) bez sprawdzenia wartości zwracanej przez ese_read(). Gdy dasd_eckd_ese_read() zwracało błąd przed wyzerowaniem bufora docelowego, warstwa blokowa otrzymywała niezerowane, niezinicjalizowane dane zamiast zer.

W jądrze Linux w sterowniku s390/dasd kilka procedur obsługi sysfs show/store wywołuje funkcję zwrotną dyscypliny, która odwołuje się do device->private. Podczas dasd_generic_set_online() dyscyplina jest przypisywana przed alokacją device->private przez check_device(), więc nieuprzywilejowany odczyt jednego z tych ogólnodostępnych atrybutów w tym oknie powoduje dereferencję wskaźnika NULL i panikę jądra.

W jądrze Linux w sterowniku s390/dasd funkcja dasd_default_erp_postaction() kopiuje stan czasu i urządzenia z zakończonego żądania ERP do żądania oryginalnego, ale pomija proc_bytes. Żądanie częściowo zakończone (odczyt ESE jeszcze nieprzydzielonego toru zwraca mniej bajtów niż żądano), a następnie odzyskane przez łańcuch ERP, traci długość częściowego ukończenia, przez co __dasd_cleanup_cqr() kończy całe żądanie zamiast zakolejkować resztę, zwracając wyzerowane dane dla nieodczytanej części.

W jądrze Linux w sterowniku PCI plda funkcja plda_pcie_irq_domain_deinit() usuwa pcie->event_domain przez irq_domain_remove(), ale poszczególne przerwania zdarzeń zmapowane z tej domeny są żądane przez devm_request_irq() w plda_init_interrupts(). Zwolnienie free_irq() dla przerwania zarządzanego przez devres jest odraczane do czasu po powrocie z probe()/remove(), więc irq_domain_remove() może zwolnić wewnętrzne dane domeny, zanim odroczone free_irq() zostanie wykonane, co prowadzi do dereferencji już zwolnionej domeny (use-after-free).

W jądrze Linux w sterowniku PCI plda funkcja plda_init_interrupts() inicjalizuje domeny przerwań i tworzy mapowania, ale nie cofa ich, gdy późniejszy krok zawiedzie. Jeśli platform_get_irq() lub którekolwiek irq_create_mapping() zawiedzie, domeny nigdy nie zostają zdeinicjalizowane, a port->intx_irq pozostaje zainicjalizowany, co prowadzi do wycieku domen przerwań.

W jądrze Linux w sterowniku iommu/amd funkcja iommu_call_iopf_notifier() wyszukuje requestera przez pci_get_domain_bus_and_slot(), co zwraca urządzenie PCI z zwiększonym licznikiem referencji. Ani ścieżka sukcesu iommu_report_device_fault(), ani ścieżka przerwania nie zwalniają tej referencji, więc każde obsłużone żądanie PPR powoduje wyciek referencji urządzenia PCI.

W jądrze Linux w sterowniku iommu/msm funkcja msm_iommu_probe() dodaje zarządzany przez devm obiekt IOMMU do qcom_iommu_devices przed dodaniem urządzenia sysfs IOMMU i zarejestrowaniem go w rdzeniu IOMMU. Jeśli iommu_device_sysfs_add() lub iommu_device_register() zawiedzie, obiekt pozostaje na liście qcom_iommu_devices, a rdzeń sterownika zwalnia alokację devm, pozostawiając wiszący wpis listy, który może być później dereferencjonowany.

W jądrze Linux w sterowniku iommu/sva funkcja iommu_attach_device_pasid() instaluje nowy uchwyt SVA w wyszukiwaniu PASID grupy, zanim iommu_sva_bind_device() zwróci wynik. Współbieżne bind może znaleźć i ponownie użyć ten sam uchwyt po zwolnieniu iommu_sva_lock. Pole handle->dev było inicjalizowane po zwolnieniu iommu_sva_lock, co pozostawia okno, w którym wyścigowy bind może zwrócić uchwyt z wciąż NULL wskaźnikiem dev, a następnie iommu_sva_unbind_device() może go dereferencjonować przez handle->dev->iommu_group.

W jądrze Linux w sterowniku iommu/tegra241-cmdqv funkcja tegra241_vintf_init_vsid() programuje dostarczony przez gościa vSID do pola SID_MATCH, którego pole VIRT_SID obejmuje bity [20:1] z bitem 0 jako flagą włączenia dopasowania, więc sprzęt dopasowuje tylko 20-bitowy Stream ID. Sprawdzenie zakresu odrzuca jedynie virt_sid > UINT_MAX, co dopuszcza wartość znacznie szerszą niż pole; zapis "virt_sid << 1 | 0x1" odrzuca wszystkie bity powyżej 20, więc virt_sid 0x80000000 staje się SID_MATCH = 0x1, prawidłowym dopasowaniem vSID 0, przez co wpis aliasuje niewłaściwy Stream ID. Ponieważ vdev->virt_id jest kontrolowane przez gościa, VMM może to wywołać.

W jądrze Linux występuje wyciek pamięci w funkcji iommu_mock_device_add(). Gdy wywołanie device_add() zakończy się niepowodzeniem, ścieżka błędu zwalnia tylko fwspec, pozostawiając zaalokowaną strukturę dev->iommu. Problem został naprawiony poprzez wywołanie dev_iommu_free() zamiast iommu_fwspec_free().

W jądrze Linux w funkcji detect_intel_iommu() warunki żądania ACS nie uwzględniały tboot, co mogło prowadzić do błędnej konfiguracji z wyłączonym ACS, gdy IOMMU jest później wymuszane przez tboot_force_iommu(). Poprawka dodaje sprawdzenie tboot w detect_intel_iommu().

W jądrze Linux funkcja iommufd_access_notify_unmap() pomija dostęp wewnętrzny, ale najpierw wywołuje iommufd_lock_obj(), co przy sukcesie powoduje pominięcie iommufd_put_object() i wyciek referencji obiektu. Poprawka sprawdza dostęp wewnętrzny przed blokowaniem.