CVE-2022-49030
WysokieCVSS 7.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 20 - wyżej niż 20% wszystkich znanych CVE
Streszczenie
W bibliotece libbpf w jądrze Linux wykryto problem z przepełnieniem rozmiaru podczas mapowania pamięci ringbuf. Maksymalny rozmiar ringbuf na hoście x86-64 wynosi 2 GB, więc podwojona wartość max_entries może przepełnić typ u32 podczas mapowania strony producenta i stron danych. Naprawa polega na rzutowaniu rozmiaru regionu mapowania tylko do odczytu na typ __u64 i sprawdzeniu, czy nie nastąpi przepełnienie podczas mmap.
Ocena ryzyka
Przepełnienie rozmiaru może prowadzić do nieprawidłowego mapowania pamięci, co może skutkować błędami działania aplikacji korzystających z ringbuf, a w skrajnych przypadkach do naruszenia integralności pamięci.
Rekomendacja
Zaleca się aktualizację jądra Linux do wersji zawierającej poprawkę dla CVE-2022-49030. Należy również unikać używania bardzo dużych rozmiarów ringbuf w aplikacjach 32-bitowych na 64-bitowych jądrach.
Inne podatności w libbpf
Zobacz wszystkie- CVE-2025-29481Średnie
Podatność przepełnienia bufora w libbpf 1.5.0 pozwala lokalnemu atakującemu na wykonanie dowolnego kodu poprzez funkcję bpf_object__init_prog w libbpf. Strona trzecia zakwestionowała tę podatność, twierdząc, że nikt rozsądny nie powinien przekazywać niezaufanych plików ELF do libbpf działającej z uprawnieniami roota.
- CVE-2026-80675Wysokie
W libbpf w podpisanym loaderze brakuje sprawdzenia, czy mapa jest wyłączna (exclusive) przed walidacją skrótu map->sha. Bez tego inny program BPF z dostępem do mapy może zmutować jej zawartość po zamrożeniu, co pozwala na sprawdzenie na nieaktualnych danych. Poprawka dodaje sprawdzenie wyłączności.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS