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.
Published: 2026-05-08
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A flaw in the Linux kernel’s memfd live‑update (LUO) mechanism incorrectly preserves the state of folios as clean when they are unmodified. Later writes to such folios leave the kernel with a stale clean flag, so under memory pressure it may reclaim the page, causing loss of user data. The bug arises from improper handling of the dirty‑bit in memfd preservation, leading to desynchronization between serialized state and actual memory contents.

Affected Systems

All Linux kernel builds that include the memfd live‑update feature are affected. The advisory does not list specific kernel releases, so any recent kernel versions using this mechanism are potentially vulnerable.

Risk and Exploitability

The vulnerability is not listed in CISA’s KEV catalog and its EPSS score is not available, indicating that exploitation has not been widely observed. The flaw only matters on systems that use memfd LUO, such as environments performing live kernel updates. While the attack vector is not explicitly documented, it is inferred that an attacker would need to influence a process that creates a memfd with LUO for the flaw to trigger. The resulting data loss could degrade availability or data integrity but does not directly enable remote code execution or privilege escalation.

Generated by OpenCVE AI on May 9, 2026 at 03:53 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that marks all memfd folios as dirty before preservation
  • If memfd live‑update is not required, disable the LUO feature in the kernel configuration
  • After updating, restart services that depend on memfd to avoid any residual clean‑folio usage

Generated by OpenCVE AI on May 9, 2026 at 03:53 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 09 May 2026 02:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-152
CWE-665

Sat, 09 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-821
References
Metrics threat_severity

None

threat_severity

Moderate


Fri, 08 May 2026 17:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-152
CWE-665

Fri, 08 May 2026 14:45:00 +0000

Type Values Removed Values Added
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.
Title mm: memfd_luo: always dirty all folios
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-08T14:21:34.658Z

Reserved: 2026-05-01T14:12:56.007Z

Link: CVE-2026-43389

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-05-08T15:16:50.290

Modified: 2026-05-08T15:16:50.290

Link: CVE-2026-43389

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-08T00:00:00Z

Links: CVE-2026-43389 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-09T04:00:14Z

Weaknesses