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<-----
Metrics
Affected Vendors & Products
References
History
Fri, 22 Nov 2024 12:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
|
Wed, 13 Nov 2024 02:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
CPEs | cpe:/a:redhat:enterprise_linux:9 cpe:/o:redhat:enterprise_linux:9 |
Tue, 05 Nov 2024 10:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
|
Thu, 08 Aug 2024 19:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Redhat
Redhat enterprise Linux |
|
CPEs | cpe:/a:redhat:enterprise_linux:8::nfv cpe:/o:redhat:enterprise_linux:8 |
|
Vendors & Products |
Redhat
Redhat enterprise Linux |
MITRE
Status: PUBLISHED
Assigner: Linux
Published: 2024-05-01T05:19:12.112Z
Updated: 2024-12-19T08:51:15.211Z
Reserved: 2024-02-19T14:20:24.201Z
Link: CVE-2024-26960
Vulnrichment
Updated: 2024-08-02T00:21:06.048Z
NVD
Status : Awaiting Analysis
Published: 2024-05-01T06:15:12.323
Modified: 2024-11-21T09:03:29.657
Link: CVE-2024-26960
Redhat