CVE-2026-74591

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/filemap: __filemap_add_folio() restore index before retrying<br /> <br /> In __filemap_add_folio()&amp;#39;s split-a-conflict loop, xas_set_order() is<br /> applied repeatedly: each application modifies xas.xa_index, rounding it<br /> down according to the split_order attempted at that stage: and if all goes<br /> as intended, it eventually (or immediately) converges on an<br /> xas_try_split() to the required folio_order, with xas.xa_index now the<br /> same as index: then xas_store() puts the new folio into the xarray there.<br /> <br /> But if a new node was needed, and GFP_NOWAIT allocation did not get one,<br /> the lock is dropped, xas_nomem() used to allocate, and sequence retried. <br /> If (that part of) the xarray is unchanged when the lock is reacquired, no<br /> problem. But what if the conflict was meanwhile resolved by another<br /> thread (perhaps even doing the same thing, inserting a folio at that same<br /> index)? Isn&amp;#39;t there a danger of now putting our folio into the xarray at<br /> an intermediate rounded-down index? With !folio_contains() bug to follow,<br /> when CONFIG_DEBUG_VM=y is checking for that.<br /> <br /> Fix this with an xas_set_order() to restore the original xas.xa_index at<br /> the bottom of the loop, so the retry does a full re-evaluation after<br /> reacquiring the lock, and cannot reach xas_store() with the wrong index.<br /> <br /> Production was suffering from rare SIGILLs and SIGSEGVs, executable text<br /> found a page away from where it belonged, !folio_contains() bug hit when<br /> debug enabled: symptoms not seen since this patch went in.