https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 10:12:01 +0000 https://vulnerability.circl.lu/vuln/cve-2024-53079 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm/thp: fix deferred split unqueue naming and locking</p> <p>Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, &#34;Bad page state&#34;s and worse (I keep BUGs in both of those, so usually don&#39;t get to see how badly they end up without). The relevant recent changes being 6.8&#39;s mTHP, 6.10&#39;s mTHP swapout, and 6.12&#39;s mTHP swapin, improved swap allocation, and underused THP splitting.</p> <p>Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()).</p> <p>Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately).</p> <p>Swapout: mem_cgroup_swapout() has been resetting folio-&gt;memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depen…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm/thp: fix deferred split unqueue naming and locking</p> <p>Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, &#34;Bad page state&#34;s and worse (I keep BUGs in both of those, so usually don&#39;t get to see how badly they end up without). The relevant recent changes being 6.8&#39;s mTHP, 6.10&#39;s mTHP swapout, and 6.12&#39;s mTHP swapin, improved swap allocation, and underused THP splitting.</p> <p>Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()).</p> <p>Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately).</p> <p>Swapout: mem_cgroup_swapout() has been resetting folio-&gt;memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depen…</p> https://vulnerability.circl.lu/vuln/cve-2024-53079