CVE-2024-57977 is a vulnerability identified in the Linux kernel related to the memory control group (memcg) subsystem, specifically affecting the Out-Of-Memory (OOM) handling process. The issue arises when a very large number of tasks—approximately 56,000—are present in the OOM cgroup. During the OOM process, the kernel traverses all tasks in this cgroup to determine which process to kill to free memory. However, the traversal of such a large number of tasks causes a soft lockup, where the CPU becomes unresponsive for an extended period (e.g., 23 seconds as observed in the provided kernel logs). This soft lockup is triggered because the kernel does not yield the CPU or reset the watchdog timer during the lengthy traversal, causing the watchdog to detect the CPU as stuck. The root cause is that the mem_cgroup_scan_tasks function, which iterates over tasks in the OOM cgroup, does not periodically call scheduling or watchdog reset functions, leading to the CPU being monopolized for too long. The fix implemented involves inserting calls to cond_resched() every 1000 iterations within mem_cgroup_scan_tasks to allow the scheduler to reschedule other tasks and calling touch_softlockup_watchdog() during global OOM scanning to reset the watchdog timer. This prevents the CPU soft lockup by ensuring the kernel yields and the watchdog is refreshed during long task traversals. This vulnerability affects Linux kernel versions identified by the commit hash 9cbb78bb314360a860a8b23723971cb6fcb54176 and likely other versions with similar memcg OOM handling implementations. The vulnerability does not appear to have known exploits in the wild yet and does not have an assigned CVSS score. However, it can cause system instability and unresponsiveness under specific high-load conditions involving large numbers of processes in the OOM cgroup. The vulnerability is particularly relevant for environments running Linux kernels with memcg enabled and managing large numbers of processes, such as cloud infrastructure, container orchestration platforms, and large-scale virtualized environments.

For European organizations, the impact of CVE-2024-57977 can be significant in environments relying heavily on Linux-based infrastructure, especially those using containerization (e.g., Docker, Kubernetes) or cloud platforms that utilize cgroups for resource management. The soft lockup can lead to temporary system unresponsiveness, degraded performance, or even service outages if the OOM killer process becomes stuck. This can affect critical services, including web hosting, cloud services, financial transaction processing, and industrial control systems that depend on Linux servers. Organizations operating large-scale compute clusters or multi-tenant cloud environments are at higher risk, as they are more likely to encounter scenarios with thousands of processes in OOM cgroups. The resulting instability could lead to denial of service conditions, impacting availability and potentially causing cascading failures in dependent systems. While this vulnerability does not directly expose confidentiality or integrity risks, the availability impact can disrupt business operations and service level agreements. Given the widespread use of Linux in European data centers, telecom infrastructure, and government systems, this vulnerability poses a moderate to high operational risk if left unpatched, especially in high-density compute environments.

To mitigate CVE-2024-57977, European organizations should: 1. Apply the official Linux kernel patches that introduce calls to cond_resched() and touch_softlockup_watchdog() in the mem_cgroup_scan_tasks function as soon as they become available. This is the definitive fix to prevent soft lockups during OOM processing. 2. Monitor system logs for soft lockup warnings related to the OOM killer or memcg subsystem to detect potential occurrences of this issue. 3. Limit the number of processes within a single OOM cgroup where feasible, by restructuring workloads or cgroup configurations to avoid extremely large task counts that trigger the vulnerability. 4. Implement resource quotas and limits on containers and virtual machines to prevent runaway process creation that could lead to large OOM cgroups. 5. Use kernel versions that have backported this fix if upgrading to the latest mainline kernel is not immediately possible. 6. In cloud or container orchestration environments, review and adjust OOM handling policies and cgroup configurations to minimize the risk of large OOM cgroups. 7. Conduct thorough testing of kernel updates in staging environments to ensure stability before deployment in production. These steps go beyond generic advice by focusing on workload and cgroup management strategies specific to this vulnerability's trigger conditions.