CVE-2024-26960

Source
https://cve.org/CVERecord?id=CVE-2024-26960
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-26960.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2024-26960
Downstream
Related
Published
2024-05-01T05:19:12.112Z
Modified
2026-05-15T11:54:01.873669736Z
Severity
  • 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
mm: swap: fix race between free_swap_and_cache() and swapoff()
Details

In the Linux kernel, the following vulnerability has been resolved:

mm: swap: fix race between freeswapand_cache() and swapoff()

There was previously a theoretical window where swapoff() could run and teardown a swapinfostruct while a call to freeswapandcache() was running in another thread. This could cause, amongst other bad possibilities, swappagetranshugeswapped() (called by freeswapandcache()) 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 getswapdevice()/putswapdevice(), which will stall swapoff(). There was an extra check in swapinfoget() to confirm that the swap entry was not free. This isn't present in getswapdevice() 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 freeswapandcache().

Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):

--8<-----

__swapentryfree() might be the last user and result in "count == SWAPHASCACHE".

swapoff->trytounuse() will stop as soon as soon as si->inuse_pages==0.

So the question is: could someone reclaim the folio and turn si->inusepages==0, before we completed swappagetranshuge_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 freeswapandcache(). -> count == SWAPHAS_CACHE [then, preempted in the hypervisor etc.]

Process 2 quits. Calls freeswapandcache(). -> count == SWAPHAS_CACHE

Process 2 goes ahead, passes swappagetranshugeswapped(), and calls _trytoreclaimswap().

__trytoreclaimswap()->foliofreeswap()->deletefromswapcache()-> putswapfolio()->freeswapslot()->swapcachefreeentries()-> swapentryfree()->swaprangefree()-> ... WRITEONCE(si->inusepages, si->inusepages - nrentries);

What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swappagetranshugeswapped()?

--8<-----

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26960.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
4.11.0
Fixed
5.10.215
Type
ECOSYSTEM
Events
Introduced
5.11.0
Fixed
5.15.154
Type
ECOSYSTEM
Events
Introduced
5.16.0
Fixed
6.1.84
Type
ECOSYSTEM
Events
Introduced
6.2.0
Fixed
6.6.24
Type
ECOSYSTEM
Events
Introduced
6.7.0
Fixed
6.7.12
Type
ECOSYSTEM
Events
Introduced
6.8.0
Fixed
6.8.3

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-26960.json"