Homepage

CVE-2026-23097 The advisory has been revoked - it doesn't affect any version of package rtla  (opens in a new tab)

Threat Intelligence

EPSS
0.11% (2nd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-ALMALINUX10-RTLA-15660787
  • published16 Mar 2026
  • disclosed2 Mar 2026
Report a new vulnerability Found a mistake?

Introduced: 2 Mar 2026

CVE-2026-23097  (opens in a new tab)

Amendment

The AlmaLinux security team deemed this advisory irrelevant for AlmaLinux:10.

NVD Description

Note: Versions mentioned in the description apply only to the upstream rtla package and not the rtla package as distributed by AlmaLinux.

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