{"id":11202,"date":"2026-09-04T18:51:45","date_gmt":"2026-09-04T10:51:45","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-74591"},"modified":"2026-09-04T18:51:45","modified_gmt":"2026-09-04T10:51:45","slug":"cve-2026-74591","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-74591","title":{"rendered":"CVE-2026-74591 [CRITICAL] &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nmm\/filemap: __filemap"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mm\/filemap: __filemap_add_folio() restore index before retrying<\/p>\n<p>In __filemap_add_folio()&#8217;s split-a-conflict loop, xas_set_order() is<br \/>\napplied repeatedly: each application modifies xas.xa_index, rounding it<br \/>\ndown according to the split_order attempted at that stage: and if all goes<br \/>\nas intended, it eventually (or immediately) converges on an<br \/>\nxas_try_split() to the required folio_order, with xas.xa_index now the<br \/>\nsame as index: then xas_store() puts the new folio into the xarray there.<\/p>\n<p>But if a new node was needed, and GFP_NOWAIT allocation did not get one,<br \/>\nthe lock is dropped, xas_nomem() used to allocate, and sequence retried.<br \/>\nIf (that part of) the xarray is unchanged when the lock is reacquired, no<br \/>\nproblem.  But what if the conflict was meanwhile resolved by another<br \/>\nthread (perhaps even doing the same thing, inserting a folio at that same<br \/>\nindex)?  Isn&#8217;t there a danger of now putting our folio into the xarray at<br \/>\nan intermediate rounded-down index?  With !folio_contains() bug to follow,<br \/>\nwhen CONFIG_DEBUG_VM=y is checking for that.<\/p>\n<p>Fix this with an xas_set_order() to restore the original xas.xa_index at<br \/>\nthe bottom of the loop, so the retry does a full re-evaluation after<br \/>\nreacquiring the lock, and cannot reach xas_store() with the wrong index.<\/p>\n<p>Production was suffering from rare SIGILLs and SIGSEGVs, executable text<br \/>\nfound a page away from where it belonged, !folio_contains() bug hit when<br \/>\ndebug enabled: symptoms not seen since this patch went in.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>mm\/filemap: __filemap_add_folio() restore index before retrying<\/p>\n<p>In __filemap_add_folio()&#8217;s split-a-conflict loop, xas_set_order() <\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-11202","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/11202","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=11202"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=11202"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=11202"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}