一、漏洞信息
漏洞编号：CVE-2024-26960
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0
CVSS V2.0分值：
BaseScore：0.0 Low
Vector：CVSS：2.0/
漏洞简述：
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 andteardown a swap_info_struct while a call to free_swap_and_cache() wasrunning in another thread. This could cause, amongst other badpossibilities, swap_page_trans_huge_swapped() (called byfree_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 atest case. But there has been agreement based on code review that this ispossible (see link below).Fix it by using get_swap_device()/put_swap_device(), which will stallswapoff(). There was an extra check in _swap_info_get() to confirm thatthe 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 gettingthe reference and swapoff. So I ve added an equivalent check directly infree_swap_and_cache().Details of how to provoke one possible issue (thanks to David Hildenbrandfor 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 turnsi->inuse_pages==0, before we completed swap_page_trans_huge_swapped().Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages arestill 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_CACHEProcess 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 cachebut before process1 finished its call to swap_page_trans_huge_swapped()?--8<-----
漏洞公开时间：2024-05-01 14:15:12
漏洞创建时间：2024-05-30 02:05:23
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2024-26960

漏洞分析指导链接：
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
openBrain开源漏洞感知系统
漏洞补丁信息：

二、漏洞分析结构反馈
影响性分析说明：
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 andteardown a swap_info_struct while a call to free_swap_and_cache() wasrunning in another thread. This could cause, amongst other badpossibilities, swap_page_trans_huge_swapped() (called byfree_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 atest case. But there has been agreement based on code review that this ispossible (see link below).Fix it by using get_swap_device()/put_swap_device(), which will stallswapoff(). There was an extra check in _swap_info_get() to confirm thatthe 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 gettingthe reference and swapoff. So I ve added an equivalent check directly infree_swap_and_cache().Details of how to provoke one possible issue (thanks to David Hildenbrandfor 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 turnsi->inuse_pages==0, before we completed swap_page_trans_huge_swapped().Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages arestill 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_CACHEProcess 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 cachebut before process1 finished its call to swap_page_trans_huge_swapped()?--8<-----
openEuler评分：
5.5
Vector：CVSS：2.0/
受影响版本排查(受影响/不受影响)：
1.openEuler-20.03-LTS-SP1(4.19.90):受影响
2.openEuler-20.03-LTS-SP4:受影响
3.openEuler-22.03-LTS(5.10.0):受影响
4.openEuler-22.03-LTS-SP1(5.10.0):受影响
5.openEuler-22.03-LTS-SP2(5.10.0):受影响
6.openEuler-22.03-LTS-SP3:受影响
7.openEuler-22.03-LTS-SP4:不受影响
8.master(6.1.0):不受影响
9.openEuler-22.03-LTS-Next(5.10.0):不受影响
10.openEuler-24.03-LTS(6.6.0):不受影响
11.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP1(4.19.90):否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS(5.10.0):否
4.openEuler-22.03-LTS-SP1(5.10.0):否
5.openEuler-22.03-LTS-SP2(5.10.0):否
6.openEuler-22.03-LTS-SP3:否
7.master(6.1.0):否
8.openEuler-22.03-LTS-Next(5.10.0):否
9.openEuler-24.03-LTS(6.6.0):否
10.openEuler-24.03-LTS-Next(6.6.0):否
11.openEuler-22.03-LTS-SP4:否