Homepage

Deadlock The advisory has been revoked - it doesn't affect any version of package libperf  (opens in a new tab)

Threat Intelligence

EPSS
0.01% (4th 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-RHEL10-LIBPERF-15216463
  • published5 Feb 2026
  • disclosed4 Feb 2026
Report a new vulnerability Found a mistake?

Introduced: 4 Feb 2026

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

Amendment

The Red Hat security team deemed this advisory irrelevant for RHEL:10.

NVD Description

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

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.