CVE-2026-23097

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! -> removemigration_ptes() -> _rmapwalkfile() -> immaplockread() <- Waits for immaprwsem(read lock)!

hugetlbfsfallocate() -> hugetlbfspunchhole() <- Takes immaprwsem(write lock)! -> hugetlbfszeropartialpage() -> filemaplockhugetlbfolio() -> filemaplock_folio() -> _filemapgetfolio <- Waits for foliolock!

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.