CVE-2026-43404

Source
https://cve.org/CVERecord?id=CVE-2026-43404
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-43404.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-43404
Downstream
Published
2026-05-08T14:21:44.929Z
Modified
2026-07-08T08:13:27.915878245Z
Summary
mm: Fix a hmm_range_fault() livelock / starvation problem
Details

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

mm: Fix a hmmrangefault() livelock / starvation problem

If hmmrangefault() fails a foliotrylock() in doswap_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 hmmrangefault(), 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 migratedeviceunmap()->lruadddrainall() sinc lruadddrainall() 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 migratedeviceunmap(), so that there is a reason to call lruadddrainall() 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 trytomigrate(), which can happen after the call to lruadddrainall(). c) No or voluntary only preemption.

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

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

Rename migrationentrywaitonlocked() to softleafentrywait_unlock() and update its documentation to indicate the new use-case.

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

v2: - Instead of a condresched() in hmmrangefault(), eliminate the problem by waiting for the folio to be unlocked in doswappage() (Alistair Popple, Andrew Morton) v3: - Add a stub migrationentrywaitonlocked() for the !CONFIGMIGRATION case. (Kernel Test Robot) v4: - Rename migrateentrywaitonlocked() to softleafentrywaitonlocked() and update docs (Alistair Popple) v5: - Add a WARNONONCE() for the !CONFIGMIGRATION version of softleafentrywaiton_locked(). - Modify wording around function names in the commit message (Andrew Morton)

(cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215)

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43404.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
1afaeb8293c9addbf4f9140bdd22635fed763459
Fixed
94b6d0ba4b640ba23bb6c708a59316e74e5ede63
Fixed
7e6e2fc91d4b9b12ec6e137019532568ebcf2680
Fixed
b570f37a2ce480be26c665345c5514686a8a0274

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-43404.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.15.0
Fixed
6.18.19
Type
ECOSYSTEM
Events
Introduced
6.19.0
Fixed
6.19.9

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-43404.json"