Linux kernel
cpe:2.3:a:linux:linux_kernel:*:*:*:*:*:*:*, +4 more
A vulnerability in the Linux kernel's memory management can lead to a use-after-free condition in the swap subsystem. This issue arises because several subsystems, including slub, shmem, and ttm, use the page->private field but fail to clear it before freeing pages. When these pages are later allocated as high-order pages and split, the tail pages can retain stale private values. The swap subsystem relies on page->private to track swap count continuations, expecting freshly allocated pages to have a private value of zero. The presence of stale values can cause the swap_count_continued() function to incorrectly validate continuation lists, leading to iterations over uninitialized page lists containing invalid data, which can cause a system crash.
Exploitation of this vulnerability causes a use-after-free condition in the swap subsystem, leading to a crash. The kernel's Address Sanitizer (KASAN) detects this as a potential wild memory access, indicating that the system has attempted to access memory that has already been freed, but still contains residual data from the previous allocation. This can disrupt normal system operations and potentially be exploited to execute arbitrary code or cause other forms of system instability.
The vulnerability can be reproduced by allocating pages in a way that allows them to be freed without clearing the page->private field. This can be done by using subsystems that manage memory pages, such as slub, shmem, or ttm, and freeing pages without resetting their private values. Once the pages are freed, they can be reallocated as high-order pages. When these pages are split, the tail pages will retain the old private values. If these stale values are then processed by the swap subsystem, the use-after-free condition will occur, causing a crash.
The vulnerability has been addressed by modifying the free_pages_prepare() function to clear the page->private field before pages are freed. This change ensures that all freed pages have a clean state, regardless of how they were previously used. Users should upgrade to the latest version of the Linux kernel where this fix has been applied.
Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.