CVE-2026-23097
Unknown Unknown - Not Provided
Deadlock Vulnerability in Linux Kernel Hugetlb File Migration

Publication date: 2026-02-04

Last updated on: 2026-03-18

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-04
Last Modified
2026-03-18
Generated
2026-05-27
AI Q&A
2026-02-04
EPSS Evaluated
2026-05-25
NVD
CVE-2026-23097
Affected Vendors & Products
Showing 18 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.10
linux linux_kernel 5.10
linux linux_kernel 5.10
linux linux_kernel 5.10
linux linux_kernel 5.10
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 5.11 (inc) to 5.15.199 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.162 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.122 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.68 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.8 (exc)
linux linux_kernel 6.19
linux linux_kernel From 5.10.1 (inc) to 5.10.249 (exc)
linux linux_kernel From 5.9.9 (inc) to 5.10 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves a deadlock caused by incorrect lock ordering when handling hugetlb file folios. Specifically, two tasks acquire locks in conflicting orders: one task holds folio_lock and then tries to acquire i_mmap_rwsem (read lock), while another holds i_mmap_rwsem (write lock) and then tries to acquire folio_lock. This improper lock sequence can cause the system to deadlock.

The issue arises in the migration path of huge pages, where the lock ordering does not follow the documented correct sequence. The fix involves expanding the scope of the existing i_mmap_lock to cover calls to remove_migration_ptes(), restoring the proper lock order that was previously altered incorrectly.


How can this vulnerability impact me? :

This vulnerability can cause a deadlock in the Linux kernel when handling huge pages, potentially leading to system hangs or freezes. Such deadlocks can disrupt normal system operations, degrade performance, and require a system reboot to recover, impacting availability and reliability.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by correcting the lock ordering in the Linux kernel code related to hugetlb file folios.

To mitigate this vulnerability, you should update your Linux kernel to a version that includes the fix for this issue, which restores the correct lock ordering by expanding the scope of the existing i_mmap_lock to cover calls to remove_migration_ptes().


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart