Linux Kernel up to 6.8.2 free_swap_and_cache/swapoff race condition

Summaryinfo

A vulnerability classified as problematic has been found in Linux Kernel up to 6.8.2. Affected by this vulnerability is the function free_swap_and_cache/swapoff. The manipulation leads to race condition. This vulnerability is referenced as CVE-2024-26960. No exploit is available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.8.2 and classified as problematic. This issue affects the function free_swap_and_cache/swapoff. The manipulation with an unknown input leads to a race condition vulnerability. Using CWE to declare the problem leads to CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. The impact remains unknown. The summary by CVE is:

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 advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2024-26960 since 02/19/2024. The exploitation is known to be difficult. Technical details are known, but no exploit is available.

The vulnerability scanner Nessus provides a plugin with the ID 209060 (Ubuntu 16.04 LTS / 18.04 LTS : Linux kernel vulnerabilities (USN-7069-1)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 5.10.215, 5.15.154, 6.1.84, 6.6.24, 6.7.12, 6.8.3 or 6.9-rc1 eliminates this vulnerability. Applying the patch d85c11c97ecf/2da5568ee222/1ede7f1d7eed/0f98f6d2fb5f/3ce4c4c653e4/363d17e7f790/82b1c07a0af6 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (209060) and CERT Bund (WID-SEC-2024-1008). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• Oracle VM
• EMC Avamar
• IBM QRadar SIEM
• Dell NetWorker
• IBM Security Guardium
• RESF Rocky Linux
• Broadcom Brocade SANnav
• Open Source Linux Kernel
• IBM Business Automation Workflow
• IBM Spectrum Protect Plus
• Dell Avamar
• Juniper Junos Space
• IBM DataPower Gateway
• IBM Storage Scale System
• SolarWinds Security Event Manager
• Dell PowerProtect Data Domain
• Dell PowerScale OneFS

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.10.214
• 5.15.153
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.1.22
• 6.1.23
• 6.1.24
• 6.1.25
• 6.1.26
• 6.1.27
• 6.1.28
• 6.1.29
• 6.1.30
• 6.1.31
• 6.1.32
• 6.1.33
• 6.1.34
• 6.1.35
• 6.1.36
• 6.1.37
• 6.1.38
• 6.1.39
• 6.1.40
• 6.1.41
• 6.1.42
• 6.1.43
• 6.1.44
• 6.1.45
• 6.1.46
• 6.1.47
• 6.1.48
• 6.1.49
• 6.1.50
• 6.1.51
• 6.1.52
• 6.1.53
• 6.1.54
• 6.1.55
• 6.1.56
• 6.1.57
• 6.1.58
• 6.1.59
• 6.1.60
• 6.1.61
• 6.1.62
• 6.1.63
• 6.1.64
• 6.1.65
• 6.1.66
• 6.1.67
• 6.1.68
• 6.1.69
• 6.1.70
• 6.1.71
• 6.1.72
• 6.1.73
• 6.1.74
• 6.1.75
• 6.1.76
• 6.1.77
• 6.1.78
• 6.1.79
• 6.1.80
• 6.1.81
• 6.1.82
• 6.1.83
• 6.6.0
• 6.6.1
• 6.6.2
• 6.6.3
• 6.6.4
• 6.6.5
• 6.6.6
• 6.6.7
• 6.6.8
• 6.6.9
• 6.6.10
• 6.6.11
• 6.6.12
• 6.6.13
• 6.6.14
• 6.6.15
• 6.6.16
• 6.6.17
• 6.6.18
• 6.6.19
• 6.6.20
• 6.6.21
• 6.6.22
• 6.6.23
• 6.7.0
• 6.7.1
• 6.7.2
• 6.7.3
• 6.7.4
• 6.7.5
• 6.7.6
• 6.7.7
• 6.7.8
• 6.7.9
• 6.7.10
• 6.7.11
• 6.8.0
• 6.8.1
• 6.8.2

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion