CVE-2024-53079: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-53079

In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. 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()). 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). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care deferred split queue in memcg charge move path"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.

AI Analysis

Technical Summary

CVE-2024-53079 is a vulnerability in the Linux kernel's memory management subsystem, specifically related to Transparent Huge Pages (THP) deferred split queues. The issue arises from race conditions and improper locking mechanisms when handling deferred splits of THP folios under heavy system load. These race conditions can cause list_del corruptions and lead to "Bad page state" errors, which may result in kernel crashes or memory corruption. The vulnerability is linked to recent kernel changes in versions 6.8 through 6.12, including modifications to mTHP (memory THP), swapout and swapin processes, and THP splitting optimizations. The root cause involves incorrect handling of folio unqueueing from deferred split lists, particularly during swapout and memcg (memory control group) charge moves, where folios are unqueued without proper locking or state checks. This can corrupt internal kernel data structures managing memory pages, potentially destabilizing the system. The fix involves renaming and clarifying internal functions, adding WARN_ON_ONCE checks to detect misuse, and ensuring proper locking and state validation when manipulating deferred split queues. The patch also addresses memcg-related race conditions by enforcing correct unqueueing sequences and updating comments to reflect the intended behavior. While the vulnerability does not have known exploits in the wild, it affects Linux kernel versions from 5.4 through 6.12, with backports possible but not strongly recommended except for corner cases. The issue is complex and primarily impacts kernel developers and system integrators managing memory-intensive workloads with THP enabled.

Potential Impact

For European organizations, the impact of CVE-2024-53079 can be significant in environments running Linux kernels with THP enabled, especially on servers handling large memory workloads such as databases, virtualization hosts, and cloud infrastructure. The vulnerability can lead to kernel crashes or memory corruption, causing system instability, downtime, and potential data loss. This is particularly critical for sectors relying on high availability and data integrity, such as financial services, healthcare, telecommunications, and government institutions. Since the vulnerability affects kernel memory management, exploitation could disrupt critical services or trigger denial-of-service conditions. Although no direct remote exploit is known, attackers with local access or the ability to execute code on affected systems could potentially trigger the race conditions to cause instability. This elevates the risk in multi-tenant cloud environments or shared hosting platforms prevalent in Europe. Additionally, the complexity of the issue means that unnoticed kernel corruption could lead to subtle data integrity problems, complicating forensic analysis and recovery efforts. Organizations with strict compliance requirements around system reliability and data protection must prioritize addressing this vulnerability to avoid operational and regulatory repercussions.

Mitigation Recommendations

1. Update Linux kernels to versions including the patch for CVE-2024-53079 as soon as they become available, ideally starting from kernel 6.12 or appropriate backports for earlier versions in use. 2. For systems where immediate kernel upgrades are not feasible, consider disabling Transparent Huge Pages (THP) temporarily to reduce exposure, especially on critical production servers. 3. Implement rigorous monitoring of kernel logs for WARN_ON_ONCE messages related to folio_unqueue_deferred_split or bad page states, which may indicate attempts to trigger the vulnerability or system instability. 4. In environments using memory control groups (memcg), review and audit memory management configurations to ensure they align with updated kernel behaviors and avoid deprecated charge move paths. 5. Conduct thorough testing of kernel updates in staging environments that replicate production memory workloads to detect any regressions or side effects from the patch. 6. Harden local access controls and restrict unprivileged user capabilities to minimize the risk of local exploitation. 7. Collaborate with Linux distribution vendors to obtain timely security updates and backports tailored to specific enterprise kernels in use. 8. Document and train system administrators on the nature of this vulnerability and the importance of kernel memory management hygiene to prevent misconfigurations that could exacerbate the issue.