CVE-2024-57977

What it actually does

Soft lockup in mem_cgroup_scan_tasks during OOM when traversing thousands of tasks in a cgroup without rescheduling, causing watchdog timeout in console_unlock and printk paths.

Why it matters to the business

System availability loss and potential forced reboots on hosts running containers or workloads with large task counts in memory cgroups; high downstream prevalence amplifies operational risk across dependent systems.

How an attack unfolds

An attacker or workload triggers memory pressure leading to OOM kill in a cgroup containing ~56k tasks; the kernel's mem_cgroup_scan_tasks traversal exceeds watchdog thresholds, resulting in soft lockup and denial of service. Threat actor context from related kernel LPE issues may combine this for further impact.

How to fix it

Apply kernel patch adding cond_resched every 1000 iterations in mem_cgroup_scan_tasks and touch_softlockup_watchdog for global OOM; upgrade affected packages to fixed versions such as numpy (PyPI) 1.19 where applicable.

How to confirm the fix worked

Confirm presence of cond_resched calls in mem_cgroup_scan_tasks via source inspection or kernel version check; reproduce OOM with large task cgroups and verify no soft lockup in dmesg.

Typical attack path

1. Identify or create memory cgroup with high task count
2. Induce memory exhaustion to enter OOM path
3. Trigger mem_cgroup_out_of_memory and scan_tasks loop
4. Sustain traversal beyond 23s to hit soft lockup

How to detect it

Review dmesg and kernel logs for 'soft lockup' combined with 'mem_cgroup_scan_tasks' or 'dump_task' call traces; correlate with OOM killer activity in high-task cgroups.

• soft lockup - CPU.*stuck.*VM Thread
• mem_cgroup_scan_tasks+0x76/0x100
• dump_task+0x114/0x130

What your security team should do

• Prioritize patching on systems with containerized workloads or high task density cgroups
• Monitor CISA KEV status and EPSS trend for escalation
• Test OOM scenarios in staging with task counts exceeding 50k