A significant vulnerability has been discovered and resolved in the Linux kernel. This vulnerability results from a race condition between free_swap_and_cache() and swapoff() functions, which could lead to potential crashes, data corruption, and other problematic consequences. Though this issue had only been theoretical up until now, it is essential to understand what it is and how it has been fixed to ensure your Linux-based systems are secure and reliable.
Vulnerability Background and Exploit Details
The vulnerability stems from a theoretical window in which the swapoff() function could run and tear down a swap_info_struct while a separate call to free_swap_and_cache() was running in another thread. This situation could result in swap_page_trans_huge_swapped() (called by free_swap_and_cache()) accessing freed memory for swap_map.
The issue was initially thought to be a theoretical problem without practical implications. However, code reviews and further investigation provided by David Hildenbrand have led to the agreement that this vulnerability is possible and therefore needs to be addressed.
To remedy this problem, the Linux kernel developers applied a fix that involved using get_swap_device()/put_swap_device(), stalling swapoff(). Additionally, an extra check previously present in _swap_info_get() was added directly in free_swap_and_cache().
Exploit Scenario
It is essential to understand how this vulnerability could be exploited to appreciate the fix employed. The exploit scenario is as follows:
1. Two processes operate on a 2 MiB folio in the swap cache, with both the subpages of this folio being referenced by swap entries. Process 1 references subpage , while Process 2 references subpage 1.
2. Process 1 terminates, calling free_swap_and_cache(), which results in a count of SWAP_HAS_CACHE. At this point, it is preempted in the hypervisor.
3. Process 2 terminates and calls free_swap_and_cache() as well, resulting in another count of SWAP_HAS_CACHE.
Process 2 then proceeds, passing swap_page_trans_huge_swapped() and calling __try_to_reclaim_swap().
5. It is at this point that the issue could manifest, with nothing stopping swapoff() from executing after Process 2 reclaims the swap cache but before Process 1 completes its call to swap_page_trans_huge_swapped().
Original References and Further Reading
This vulnerability's initial discussion and resolution can be found on the Linux kernel mailing list, with contributions from various developers actively working on the kernel:
- Initial Vulnerability Report
- Proposed Fix and Discussion
Conclusion
In conclusion, the Linux kernel developers have successfully addressed a crucial vulnerability present in the kernel relating to the race condition between free_swap_and_cache() and swapoff() functions - CVE-2024-26960. While this vulnerability was previously thought to be theoretical, it became evident that it was a possible vulnerability in practice. It is crucial to keep the Linux kernel up-to-date and apply the latest patches to maintain the overall security and integrity of the systems you operate.
Timeline
Published on: 05/01/2024 06:15:12 UTC
Last modified on: 08/02/2024 00:21:06 UTC