CVE-2026-23097
Description
In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.
How to fix
- linux linux_kernel5.10, 5.10.249, 5.15.199, 6.1.162, 6.6.122, 6.12.68, 6.18.8 or later
Affected products
| Product | Affected versions | Fixed in |
|---|---|---|
| linux linux_kernel | 5.9.9 ≤ v < 5.10, 5.10.1 ≤ v < 5.10.249, 5.11 ≤ v < 5.15.199, 5.16 ≤ v < 6.1.162, 6.2 ≤ v < 6.6.122, 6.7 ≤ v < 6.12.68, 6.13 ≤ v < 6.18.8, 5.10, 6.19 | 5.10, 5.10.249, 5.15.199, 6.1.162, 6.6.122, 6.12.68, 6.18.8 |
Check your version
Choose the product and enter the version you run to see whether it falls in the affected range.
Attack Surface Management
See the assets tied to your domains, the technologies they run and known vulnerabilities in one list.