{"id":"AZL-77181","summary":"CVE-2026-23097 affecting package kernel for versions less than 6.6.126.1-1","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nmigrate: correct lock ordering for hugetlb file folios\n\nSyzbot has found a deadlock (analyzed by Lance Yang):\n\n1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).\n2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire\nfolio_lock.\n\nmigrate_pages()\n  -\u003e migrate_hugetlbs()\n    -\u003e unmap_and_move_huge_page()     \u003c- Takes folio_lock!\n      -\u003e remove_migration_ptes()\n        -\u003e __rmap_walk_file()\n          -\u003e i_mmap_lock_read()       \u003c- Waits for i_mmap_rwsem(read lock)!\n\nhugetlbfs_fallocate()\n  -\u003e hugetlbfs_punch_hole()           \u003c- Takes i_mmap_rwsem(write lock)!\n    -\u003e hugetlbfs_zero_partial_page()\n     -\u003e filemap_lock_hugetlb_folio()\n      -\u003e filemap_lock_folio()\n        -\u003e __filemap_get_folio        \u003c- Waits for folio_lock!\n\nThe migration path is the one taking locks in the wrong order according to\nthe documentation at the top of mm/rmap.c.  So expand the scope of the\nexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.\n\nThis is (mostly) how it used to be after commit c0d0381ade79.  That was\nremoved by 336bf30eb765 for both file & anon hugetlb pages when it should\nonly have been removed for anon hugetlb pages.","modified":"2026-08-28T17:48:01.999672058Z","published":"2026-02-04T17:16:20Z","upstream":["CVE-2026-23097"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23097"}],"affected":[{"package":{"name":"kernel","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/kernel"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.126.1-1"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-77181.json"}}],"schema_version":"1.9.0"}