CVE-2024-26960 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/26/2026
The vulnerability identified as CVE-2024-26960 resides within the Linux kernel's memory management subsystem, specifically in the interaction between swap handling functions during concurrent operations. This issue manifests as a race condition between the `free_swap_and_cache()` function and the `swapoff()` system call, which can lead to memory corruption and system instability. The flaw occurs when `swapoff()` attempts to tear down a `swap_info_struct` while another thread is executing `free_swap_and_cache()`, potentially causing the latter to access freed memory locations, particularly within the `swap_map` data structure. This type of race condition falls under the category of concurrency issues commonly addressed by CWE-362, which deals with concurrent execution using lock objects.
The technical root cause of this vulnerability stems from the lack of proper synchronization mechanisms during the transition from swap cache management to swap device teardown. When `swapoff()` begins its operation, it can proceed to free swap structures even while other threads are still processing swap entries through `free_swap_and_cache()`. The `free_swap_and_cache()` function, which handles the cleanup of swap cache entries, calls `swap_page_trans_huge_swapped()` to manage large page mappings, but this function may attempt to access memory that has already been freed by the concurrent `swapoff()` operation. This scenario represents a classic race condition where the timing of memory deallocation and access operations creates an undefined state, potentially leading to memory corruption or kernel panics.
The operational impact of this vulnerability extends beyond simple system instability, as it can compromise the integrity of the kernel's memory management subsystem and potentially provide attackers with opportunities for privilege escalation or denial of service. The race condition can manifest in scenarios involving multiple processes simultaneously managing swap entries, particularly when large page mappings are involved. This vulnerability aligns with ATT&CK technique T1068, which covers "Exploitation for Privilege Escalation" and T1499, "Endpoint Denial of Service", since a successful exploitation could lead to system crashes or unauthorized access to system resources. The theoretical nature of this vulnerability means that while it has not been proven to be exploitable in practice, the potential exists for it to be triggered under specific timing conditions, especially in high-concurrency environments or when swap operations are frequent.
The fix implemented for CVE-2024-26960 involves introducing proper reference counting and synchronization through the use of `get_swap_device()` and `put_swap_device()` functions, which effectively serialize access to swap devices and prevent `swapoff()` from proceeding while active swap operations are in progress. This approach ensures that `swapoff()` operations are stalled until all pending `free_swap_and_cache()` calls complete, thereby eliminating the race condition. Additionally, the fix includes adding a direct check within `free_swap_and_cache()` to verify that swap entries are not marked as freed, which provides an additional layer of protection against accessing invalid memory locations. This solution addresses the underlying concurrency issue by ensuring proper lifecycle management of swap device references and aligns with security best practices for preventing race conditions in kernel-level code. The implementation follows established patterns for kernel synchronization and memory management, reducing the attack surface and improving overall system stability during concurrent swap operations.