CVE-2026-90409
NieznaneStreszczenie
W jądrze Linux sterownik drm/panthor nie sprawdza, czy mapowania vm_bind dla buforów widocznych dla użytkownika nie nakładają się na region zarezerwowany dla mapowań buforów jądra. Brak tej weryfikacji może prowadzić do konfliktów w przestrzeni adresowej. Poprawka dodaje sprawdzenie nakładania się zakresów oraz zabezpieczenie przed przepełnieniem 64-bitowego zakresu.
Ocena ryzyka
Nakładanie się mapowań może prowadzić do uszkodzenia pamięci lub błędnego działania sterownika GPU, co potencjalnie umożliwia eskalację uprawnień lub destabilizację systemu. Dotyczy platform z GPU Mali obsługiwanym przez Panthor.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla sterownika drm/panthor. Ogranicz dostęp do urządzeń GPU dla niezaufanych użytkowników do czasu aktualizacji.
Inne podatności w Linux kernel (drm/panthor)
Zobacz wszystkie- CVE-2026-89826Wysokie
W jądrze Linux funkcja panthor_fw_read_build_info() sterownika drm/panthor sprawdza zakres metadanych za pomocą dodawania dwóch pól u32 (hdr.meta_start + hdr.meta_size), co może się przekręcić i przepuścić zakres poza granicami. Dodatkowo odczyt prefiksu "git_sha: " następuje bez sprawdzenia długości metadanych, a meta_size == 0 może spowodować niedomiar indeksu terminatora NULL.
- CVE-2026-89825Wysokie
W jądrze Linux funkcje panthor_init_cs_iface() i panthor_init_csg_iface() sterownika drm/panthor walidują przesunięcia interfejsu sterowania firmware za pomocą arytmetyki 32-bitowej i rozmiaru struktur opakowujących hosta, co może się przekręcić przed sprawdzeniem granic. Sprawdzany rozmiar nie odpowiada rzeczywistemu rozmiarowi mapowanego interfejsu sterowania firmware.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Add vm_bind region with kbo range overlap check When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources.