Linux Kernel Folio Reference Count Vulnerability in Memory Management

A vulnerability in the Linux kernel's memory management system has been addressed. The issue arose because the 'nr_pages' variable was not properly initialized at the beginning of each loop iteration in the 'try_to_unmap_one' function. This oversight allowed the 'nr_pages' value, calculated by a previous 'folio_unmap_pte_batch' call, to be incorrectly reused in later iterations that did not invoke 'folio_unmap_pte_batch' again. The vulnerability was particularly problematic with device-exclusive mappings of anonymous, droppable large folios, leading to corruption of the folio's reference and map counts. The flaw was introduced during the implementation of batched unmapping for lazy-free large folios, as device-exclusive handling only applies to anonymous folios.

Impact

Exploitation of this vulnerability could cause the kernel to crash, due to corruption of the folio reference and map counts.

Reproduction

To reproduce this vulnerability, mmap a 64K large folio with MAP_ANONYMOUS and MAP_DROPPABLE flags. Then, call madvise with the MADV_FREE option to free the memory. After that, make the last page device-exclusive using the HMM_DMIRROR_EXCLUSIVE option. Finally, trigger node reclaim through the sysfs interface. During the reclamation process, the 'try_to_unmap_one' function will incorrectly handle the 'nr_pages' variable, leading to a crash.

Remediation

Users can apply the latest patches available in the Linux kernel stable tree to address this vulnerability.