linux-cve-announce - CVE-2024-26960: mm: swap: fix race between free_swap_and

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2024050129-CVE-2024-26960-ad6b@gregkh>
Date: Wed,  1 May 2024 07:21:50 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-26960: mm: swap: fix race between free_swap_and_cache() and swapoff()

Description
===========

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<-----

The Linux kernel CVE team has assigned CVE-2024-26960 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.11 with commit 7c00bafee87c and fixed in 5.10.215 with commit d85c11c97ecf
	Issue introduced in 4.11 with commit 7c00bafee87c and fixed in 5.15.154 with commit 2da5568ee222
	Issue introduced in 4.11 with commit 7c00bafee87c and fixed in 6.1.84 with commit 1ede7f1d7eed
	Issue introduced in 4.11 with commit 7c00bafee87c and fixed in 6.6.24 with commit 0f98f6d2fb5f
	Issue introduced in 4.11 with commit 7c00bafee87c and fixed in 6.7.12 with commit 3ce4c4c653e4
	Issue introduced in 4.11 with commit 7c00bafee87c and fixed in 6.8.3 with commit 363d17e7f790
	Issue introduced in 4.11 with commit 7c00bafee87c and fixed in 6.9-rc1 with commit 82b1c07a0af6

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-26960
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	mm/swapfile.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d
	https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e
	https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a
	https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a
	https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39
	https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b
	https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e