Katalog CVE

CVE-2026-63950

WysokieCVSS 7.8
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.16%

Percentyl 6 - wyżej niż 6% wszystkich znanych CVE

Streszczenie

W jądrze Linux wykryto podatność w funkcji try_to_unmap_one w mm/rmap, gdzie zmienna nr_pages nie jest inicjalizowana na początku każdej iteracji pętli. Może to prowadzić do ponownego użycia wartości z poprzedniego wywołania folio_unmap_pte_batch(), co skutkuje uszkodzeniem liczników referencji/mapowania folio. Problem występuje przy łączeniu folio z flagą MAP_DROPPABLE, wywołaniu madvise(MADV_FREE) i użyciu HMM_DMIRROR_EXCLUSIVE, co może doprowadzić do awarii jądra.

Ocena ryzyka

Ryzyko polega na możliwym uszkodzeniu struktury pamięci jądra, co może prowadzić do awarii systemu (kernel crash) w wyniku naruszenia liczników referencji lub mapowania folio. Atakujący z lokalnym dostępem może wykorzystać tę podatność do destabilizacji systemu.

Rekomendacja

Zaleca się natychmiastową aktualizację jądra Linux do wersji zawierającej poprawkę inicjalizującą nr_pages na 1 na początku każdej iteracji pętli w try_to_unmap_one. Należy monitorować oficjalne biuletyny bezpieczeństwa dystrybucji Linux.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one Initialize nr_pages to 1 at the start of each loop iteration, like folio_referenced_one() does. Without this, nr_pages computed by a previous folio_unmap_pte_batch() call can be reused on a later iteration that does not run folio_unmap_pte_batch() again. mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call madvise(MADV_FREE), then make the last page device-exclusive via HMM_DMIRROR_EXCLUSIVE. Trigger node reclaim through sysfs. Now, in try_to_unmap_one(), we will first clear the first 15 out of 16 entries mapping the lazyfree folio. This will set nr_pages to 15. In the next pvmw walk, this nr_pages gets reused on a device-exclusive pte, thus potentially corrupting folio refcount/mapcount. At the moment, I have a userspace program which can make the kernel spit out a trace, but the blow up is in folio_referenced_one(), because there are existing bugs in the interaction between device-private and rmap (which too I am investigating). I did a one liner kernel change to avoid going into folio_referenced_one(), and the kernel blows up at folio_remove_rmap_ptes in try_to_unmap_one which is what I wanted. Note that the bug is there not since file folio batching but lazyfree folio batching, since device-exclusive only works for anonymous folios. Userspace visible effect is simply kernel crashing somewhere due to refcount/mapcount corruption.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS