CVE-2026-43389

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: memfd_luo: always dirty all folios<br /> <br /> A dirty folio is one which has been written to. A clean folio is its<br /> opposite. Since a clean folio has no user data, it can be freed under<br /> memory pressure.<br /> <br /> memfd preservation with LUO saves the flag at preserve(). This is<br /> problematic. The folio might get dirtied later. Saving it at freeze()<br /> also doesn&amp;#39;t work, since the dirty bit from PTE is normally synced at<br /> unmap and there might still be mappings of the file at freeze().<br /> <br /> To see why this is a problem, say a folio is clean at preserve, but gets<br /> dirtied later. The serialized state of the folio will mark it as clean. <br /> After retrieve, the next kernel will see the folio as clean and might try<br /> to reclaim it under memory pressure. This will result in losing user<br /> data.<br /> <br /> Mark all folios of the file as dirty, and always set the<br /> MEMFD_LUO_FOLIO_DIRTY flag. This comes with the side effect of making all<br /> clean folios un-reclaimable. This is a cost that has to be paid for<br /> participants of live update. It is not expected to be a common use case<br /> to preserve a lot of clean folios anyway.<br /> <br /> Since the value of pfolio-&gt;flags is a constant now, drop the flags<br /> variable and set it directly.