CVE-2024-57977 in Linux
Summary
by MITRE • 02/27/2025
In the Linux kernel, the following vulnerability has been resolved:
memcg: fix soft lockup in the OOM process
A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered.
watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]
CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0
This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process.
To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/24/2026
The vulnerability identified as CVE-2024-57977 represents a critical soft lockup issue within the Linux kernel's memory control group implementation, specifically affecting the Out-of-Memory (OOM) handling mechanism. This flaw manifests when the system encounters a large number of tasks—approximately 56,000—within a single OOM cgroup, causing the kernel to experience prolonged traversal times during OOM processing. The issue was triggered by a watchdog mechanism that detected a CPU thread stuck for 23 seconds, indicating a system hang or soft lockup condition. The stack trace reveals execution paths through console_unlock, vprintk_emit, dump_task, and ultimately mem_cgroup_scan_tasks, which indicates the kernel was stuck during the process of scanning tasks within the memory cgroup during an OOM event.
The root cause of this vulnerability lies in the inefficient traversal of tasks within the memory cgroup during OOM processing. The function mem_cgroup_scan_tasks does not implement periodic yielding or rescheduling, leading to extended blocking periods when dealing with large numbers of tasks. This behavior directly violates the principle of responsive system design, where kernel threads must periodically yield to prevent indefinite blocking. The lack of periodic rescheduling causes the watchdog to detect the system as unresponsive, particularly in high-load scenarios where numerous processes are simultaneously in an OOM state. This issue can be categorized under CWE-704, which relates to incorrect behavior in kernel code, and more specifically aligns with CWE-667, which addresses improper locking mechanisms in concurrent systems.
The operational impact of this vulnerability is severe, as it can lead to complete system unresponsiveness during critical OOM events. When the kernel becomes stuck during memory cgroup traversal, all system resources become unavailable, potentially causing service disruptions, data loss, or complete system crashes. This vulnerability is particularly concerning in cloud and virtualized environments where memory constraints are common and large numbers of processes may be simultaneously competing for resources. The issue directly impacts system reliability and availability, as the watchdog mechanism is designed to detect and report such failures, but the system remains unresponsive during the critical OOM handling phase. The vulnerability demonstrates a failure in kernel design to handle large-scale concurrent operations without introducing system-wide blocking conditions.
The fix for this vulnerability involves implementing periodic rescheduling within the mem_cgroup_scan_tasks function to prevent indefinite blocking during task traversal. Specifically, the solution requires calling cond_resched() every 1000 iterations to allow other kernel threads to execute, and for global OOM scenarios, calling touch_softlockup_watchdog() at the same interval to prevent watchdog timeouts. This approach aligns with established kernel development practices for handling large data structures in kernel space, ensuring that long-running operations do not block system responsiveness. The mitigation strategy follows ATT&CK technique T1490, which involves system resource exhaustion, by preventing the exploitation of resource management flaws that could lead to system unresponsiveness. The solution addresses the fundamental design flaw by introducing cooperative multitasking principles into kernel memory management code, ensuring that kernel threads remain responsive even when processing large numbers of tasks during OOM conditions. This fix maintains system stability while preserving the integrity of memory cgroup management and OOM handling mechanisms.