CVE-2024-57977: memcg: fix soft lockup in the OOM process
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.
Security readout for executives and security teams
Plain-English summary
CVE-2024-57977 is a Linux kernel availability bug in memory-cgroup out-of-memory handling. When a very large number of tasks are in an OOM cgroup, the kernel can spend too long scanning and printing task information, triggering a soft lockup. Evidence points to operational disruption, not data theft or privilege escalation.
Executive priority
Handle through normal kernel patch governance, with higher priority for high-density Linux platforms where an OOM event could affect service availability. No source in the bundle supports emergency treatment or active exploitation.
Technical view
The flaw is in mem_cgroup_scan_tasks during OOM reporting. With about 56,000 tasks in the OOM cgroup, task traversal caused a watchdog soft lockup. The kernel fix adds periodic rescheduling for memcg OOM scans and watchdog touches for global OOM scans every 1000 iterations.
Likely exposure
Exposure is most likely on Linux systems using affected kernel versions or downstream builds that include the vulnerable memcg OOM path. Container, virtualization, and dense multi-process hosts are more relevant because they can accumulate many tasks in cgroups. Product-specific downstream exposure is not fully established in the bundle.
Exploitation context
The source bundle does not show CISA KEV listing, public exploitation, or exploit tooling. Triggering appears to require an extreme OOM condition with thousands of tasks in a cgroup. Treat this as an availability and resilience issue unless vendor advisories say otherwise.
Researcher notes
The bug is a scheduler/watchdog starvation issue during OOM task scanning, not a memory corruption report. The fix behavior is described, but the bundle lacks CVSS, CWE, proof-of-concept status, and detailed downstream affected-product matrices.
Mitigation direction
Upgrade to a vendor kernel containing the referenced stable fixes.
Check distribution advisories for backported kernel packages.
Prioritize dense container, virtualization, and multi-tenant Linux hosts.
Monitor vendor advisories from Linux distributions and appliance suppliers.
Review OOM and soft-lockup alerts for affected systems.
Validation and detection
Inventory running kernel versions across Linux fleets.
Map kernels against vendor fixed package guidance.
Check whether memcg or container workloads are heavily used.
Review logs for watchdog soft lockup and OOM traces.
Confirm fixed commits or distro backports are present.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-57977 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
2ADP providers
14Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Feb 27, 2025, 02:07 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.