CVE-2026-43404
Memory Corruption in Linux Kernel mm Subsystem
Publication date: 2026-05-08
Last updated on: 2026-05-08
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is resolved by updating the Linux kernel to a version that includes the fix for the hmm_range_fault() livelock/starvation problem.
Specifically, the fix involves waiting for the folio to be unlocked if folio_trylock() fails in do_swap_page(), preventing the livelock condition.
Therefore, the immediate mitigation step is to apply the kernel patch or upgrade to a kernel version that contains this fix.
Can you explain this vulnerability to me?
This vulnerability exists in the Linux kernel's memory management subsystem, specifically in the hmm_range_fault() function. When hmm_range_fault() tries to acquire a lock on a device-private folio for migration to RAM and fails, it spins waiting for the lock to be released. If the process holding the lock depends on a work item scheduled on the same CPU as the spinning hmm_range_fault(), that work item can be starved, causing a livelock or starvation situation that never resolves.
This situation can occur when the process holding the device-private folio lock is stuck in migrate_device_unmap()->lru_add_drain_all(), where lru_add_drain_all() requires a short work-item to run on all online CPUs to complete. The spinning hmm_range_fault() prevents this work-item from running, causing the livelock.
The vulnerability requires specific conditions, such as both zone device and system memory folios being considered in migrate_device_unmap(), the zone device folio having an initial mapcount greater than 1, and no or voluntary only preemption.
The issue was resolved by changing the code to wait for the folio to be unlocked if folio_trylock() fails in do_swap_page(), preventing the spinning and thus the livelock.
How can this vulnerability impact me? :
This vulnerability can cause a livelock or starvation situation in the Linux kernel's memory management, where a process spins indefinitely waiting for a lock that cannot be released because the work needed to release it is starved.
The impact is that system resources could be tied up, potentially leading to degraded system performance or unresponsiveness in scenarios involving device memory migration.
However, the conditions required for this vulnerability to manifest are quite specific and unlikely, so the practical impact may be limited to certain workloads or test scenarios.