CVE-2026-43389 Details
Description
In the Linux kernel, the following vulnerability has been resolved: mm: memfd_luo: always dirty all folios A dirty folio is one which has been written to. A clean folio is its opposite. Since a clean folio has no user data, it can be freed under memory pressure. memfd preservation with LUO saves the flag at preserve(). This is problematic. The folio might get dirtied later. Saving it at freeze() also doesn't work, since the dirty bit from PTE is normally synced at unmap and there might still be mappings of the file at freeze(). To see why this is a problem, say a folio is clean at preserve, but gets dirtied later. The serialized state of the folio will mark it as clean. After retrieve, the next kernel will see the folio as clean and might try to reclaim it under memory pressure. This will result in losing user data. Mark all folios of the file as dirty, and always set the MEMFD_LUO_FOLIO_DIRTY flag. This comes with the side effect of making all clean folios un-reclaimable. This is a cost that has to be paid for participants of live update. It is not expected to be a common use case to preserve a lot of clean folios anyway. Since the value of pfolio->flags is a constant now, drop the flags variable and set it directly.
A vulnerability in the Linux kernel's memory management related to the 'memfd' feature has been addressed. This issue arises when 'memfd' preservation with Live Update Option (LUO) saves the state of memory folios. A folio can be clean (not written to) or dirty (written to), and a clean folio can be reclaimed under memory pressure. The problem occurs because saving the folio state at the 'preserve' stage can lead to data loss. If a folio is clean when preserved but gets dirtied later, the serialized state will incorrectly mark it as clean. When retrieved, the kernel may attempt to reclaim it, resulting in the loss of user data. To mitigate this, all folios are now marked as dirty, ensuring they are not reclaimed, but this also means clean folios become un-reclaimable after a live update, a necessary trade-off for preserving data integrity during updates.
Users can upgrade to the latest version of the Linux kernel where this vulnerability has been fixed. Instructions for downloading the patched version are available on the Linux kernel official website.
Metrics
CVSS 4.0 Severity and Vector Strings:
No CVSS 4.0 data is available for this CVE.
CVSS 3.x Severity and Vector Strings:
No data available for CVSS Version 2.0 on this CVE.
No SSVC data is available for this CVE.
References to Advisories, Solutions, and Tools
By selecting these links, you will be leaving this site. These are references gathered from the official CVE record and are not endorsed by Volerion.
| URL | Source(s) | Tag(s) |
|---|---|---|
| https://git.kernel.org/stable/c/7e04bf1f33151a30e06a65b74b5f2c19fc2be128 | kernel.org | Patch |
| https://git.kernel.org/stable/c/e901c871d4b592f0042e30f3a0f031eae79744ec | kernel.org | Patch |
Weakness Enumeration
| CWE-ID | CWE Name | Source |
|---|---|---|
| NVD-CWE-noinfo | Insufficient Information to Classify Weakness | [email protected] |
Affected Products
| Product | Versions |
|---|---|
| linux linux kernel | >= 6.19, < 6.19.9 7.0 rc1 7.0 rc2 7.0 rc3 |
CPE
Remediation
| |
Change History
3 change records found show changes
| Date | Action | Recorded By |
|---|---|---|
| Jun 17, 2026 | CVE Modified | kernel.org |
| May 26, 2026 | Initial Analysis | [email protected] |
| May 8, 2026 | New CVE Received | kernel.org |