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 foliolock, then tries to acquire immaprwsem(read lock). 2) Task (5754): Holds immaprwsem(write lock), then tries to acquire foliolock.
migratepages() -> migratehugetlbs() -> unmapandmovehugepage() <- Takes foliolock! -> removemigrationptes() -> _rmapwalkfile() -> immaplockread() <- Waits for immap_rwsem(read lock)!
hugetlbfsfallocate() -> hugetlbfspunchhole() <- Takes immaprwsem(write lock)! -> hugetlbfszeropartialpage() -> filemaplockhugetlbfolio() -> filemaplockfolio() -> _filemapgetfolio <- 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 immaplock to cover the calls to removemigrationptes() 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.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/23xxx/CVE-2026-23097.json",
"cna_assigner": "Linux"
}