CVE-2026-23097: Linux kernel · migrate: correct lock ordering for hugetlb file folios
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in e7396d23f9d5739f56cf9ab430c3a169f5508394 : update Linux kernel when convenient.
Data as of 26 Oct 2026, 14:18 UTC
Rated by Threat Radar · No CVSS score from NVD or the CNA
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 1% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Limited control over the software or limited information exposure
CISA SSVC assessment, 2026-06-10.
- Patch
- Available – fixed in e7396d23f9d5739f56cf9ab430c3a169f5508394, b75070823b89009f5123fd0e05a8e0c3d39937c1, b7880cb166ab62c2409046b2347261abf701530e +5
Exploitation evidence
Disclosed: evidence found.
CVE published 4 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
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.
References
- git.kernel.org/stable/c/e7396d23f9d5739f56cf9ab430c3a169f5508394 (opens in a new tab)
- git.kernel.org/stable/c/ad97b9a55246eb940a26ac977f80892a395cabf9 (opens in a new tab)
- git.kernel.org/stable/c/5edb9854f8df5428b40990a1c7d60507da5bd330 (opens in a new tab)
- git.kernel.org/stable/c/526394af4e8ade89cacd1a9ce2b97712712fcc34 (opens in a new tab)
- git.kernel.org/stable/c/b75070823b89009f5123fd0e05a8e0c3d39937c1 (opens in a new tab)
- git.kernel.org/stable/c/1b68efce6dd483d22f50d0d3800c4cfda14b1305 (opens in a new tab)
- git.kernel.org/stable/c/b7880cb166ab62c2409046b2347261abf701530e (opens in a new tab)