{"id":21682,"date":"2026-09-12T04:31:31","date_gmt":"2026-09-11T20:31:31","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89760"},"modified":"2026-09-12T04:31:31","modified_gmt":"2026-09-11T20:31:31","slug":"cve-2026-89760","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89760","title":{"rendered":"CVE-2026-89760 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nmm, swap: don&#8217;t free"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mm, swap: don&#8217;t free a hibernation slot that is in the swap cache<\/p>\n<p>A slot with a folio in the swap cache is freed when the folio leaves the<br \/>\ncache, not when its count drops.  swap_put_entries_cluster() follows that<br \/>\nrule.  swap_free_hibernation_slot() does not, it calls<br \/>\n__swap_cluster_free_entries() whether or not a folio sits on the slot.<\/p>\n<p>Cluster readahead can put one there.  It walks a raw page_cluster sized<br \/>\nwindow of offsets around the faulting entry, and a hibernation slot passes<br \/>\n__swap_cache_add_check() because it is not a folio and its count is not<br \/>\nzero.  Freeing the slot then clears the entry under that folio.<\/p>\n<p>The folio is now unreachable from the swap table, and the offset goes back<br \/>\nto the allocator.  The folio is still on the LRU though, so reclaim can<br \/>\npick it up later.  It then takes the old offset out of folio-&gt;swap and<br \/>\noverwrites the table entry there, which by then may belong to someone<br \/>\nelse.<\/p>\n<p>This bug can trigger silent memory corruption, process crashes, or data<br \/>\ninstability across completely unrelated userspace applications &#8211; typically<br \/>\noccurring when uswsusp is preparing the hibernation image.<\/p>\n<p>I found this while working on giving hibernation slots their own marker in<br \/>\nthe swap table, which I had discussed with Kairui.<br \/>\n(https:\/\/lore.kernel.org\/linux-mm\/abp7aDgYLrxF3Me8@KASONG-MC4\/) As far as<br \/>\nI know there are no reports, so there is no Reported-by\/Closes to add.<\/p>\n<p>Check for a cached folio before freeing.  The slot is then left in the<br \/>\nordinary state where only the swap cache holds it, and it is freed when<br \/>\nthe folio leaves the cache, either through the reclaim below or through<br \/>\nnormal reclaim later.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mm, swap: don&#8217;t free a hibernation slot that is in the swap cache<\/p>\n<p>A slot with a folio in the swap cache is freed when the folio le<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21682","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21682","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}