製品・ソフトウェアに関する情報
LinuxのLinux Kernelにおけるリソースのロックに関する脆弱性
Title LinuxのLinux Kernelにおけるリソースのロックに関する脆弱性
Summary

Linuxカーネルにおけるmm: hmm_range_fault()のライブロックおよびスターベーション問題が修正されました。hmm_range_fault()はdo_swap_page内でfolio_trylock()に失敗すると、ロックが取得できるまでスピンし続けます。そのため、ロックを保持するプロセスがスピンして処理の完了を待っている場合にライブロックやスターベーション状態が発生していました。この問題は特定の環境で実際に検出されており、修正としてフォリオのロック待機方法を変更して問題の再発を防止しています。将来的にはマイグレーション処理の順序を変更することで簡素化することも検討されています。

Possible impacts 当該ソフトウェアが扱う情報について、外部への漏えいは発生しません。 また、当該ソフトウェアが扱う情報について、書き換えは発生しません。 さらに、当該ソフトウェアが完全に停止する可能性があります。 そして、この脆弱性を悪用した攻撃の影響は、他のソフトウェアには及びません。 
Solution

リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。

Publication Date May 8, 2026, midnight
Registration Date May 25, 2026, 10:22 a.m.
Last Update May 25, 2026, 10:22 a.m.
CVSS3.0 : 警告
Score 5.5
Vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected System
Linux
Linux Kernel 6.15 以上 6.18.19 未満
Linux Kernel 6.19 以上 6.19.9 未満
Linux Kernel 7.0
CVE (情報セキュリティ 共通脆弱性識別子)
CWE (共通脆弱性タイプ一覧)
その他
Change Log
No Changed Details Date of change
1 [2026年05月25日]
  掲載
May 25, 2026, 10:22 a.m.

NVD Vulnerability Information
CVE-2026-43404
Summary

In the Linux kernel, the following vulnerability has been resolved:

mm: Fix a hmm_range_fault() livelock / starvation problem

If hmm_range_fault() fails a folio_trylock() in do_swap_page,
trying to acquire the lock of a device-private folio for migration,
to ram, the function will spin until it succeeds grabbing the lock.

However, if the process holding the lock is depending on a work
item to be completed, which is scheduled on the same CPU as the
spinning hmm_range_fault(), that work item might be starved and
we end up in a livelock / starvation situation which is never
resolved.

This can happen, for example if the process holding the
device-private folio lock is stuck in
migrate_device_unmap()->lru_add_drain_all()
sinc lru_add_drain_all() requires a short work-item
to be run on all online cpus to complete.

A prerequisite for this to happen is:
a) Both zone device and system memory folios are considered in
migrate_device_unmap(), so that there is a reason to call
lru_add_drain_all() for a system memory folio while a
folio lock is held on a zone device folio.
b) The zone device folio has an initial mapcount > 1 which causes
at least one migration PTE entry insertion to be deferred to
try_to_migrate(), which can happen after the call to
lru_add_drain_all().
c) No or voluntary only preemption.

This all seems pretty unlikely to happen, but indeed is hit by
the "xe_exec_system_allocator" igt test.

Resolve this by waiting for the folio to be unlocked if the
folio_trylock() fails in do_swap_page().

Rename migration_entry_wait_on_locked() to
softleaf_entry_wait_unlock() and update its documentation to
indicate the new use-case.

Future code improvements might consider moving
the lru_add_drain_all() call in migrate_device_unmap() to be
called *after* all pages have migration entries inserted.
That would eliminate also b) above.

v2:
- Instead of a cond_resched() in hmm_range_fault(),
eliminate the problem by waiting for the folio to be unlocked
in do_swap_page() (Alistair Popple, Andrew Morton)
v3:
- Add a stub migration_entry_wait_on_locked() for the
!CONFIG_MIGRATION case. (Kernel Test Robot)
v4:
- Rename migrate_entry_wait_on_locked() to
softleaf_entry_wait_on_locked() and update docs (Alistair Popple)
v5:
- Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION
version of softleaf_entry_wait_on_locked().
- Modify wording around function names in the commit message
(Andrew Morton)

(cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215)

Publication Date May 9, 2026, 12:16 a.m.
Registration Date May 9, 2026, 4:14 a.m.
Last Update May 12, 2026, 11:10 p.m.
Related information, measures and tools
Common Vulnerabilities List