CVE-2024-57977
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
A soft lockup vulnerability was found in the Linux kernel during OOM (Out-Of-Memory) handling in cgroup. The issue occurs when a very large number of processes (e.g., 56,000) are in the OOM cgroup, causing traversal to take too long and blocking the system.
Risk Assessment
The risk is that in environments with many processes in a cgroup (e.g., cloud or virtual servers), the OOM process can cause a soft lockup, leading to unresponsiveness and potential loss of service availability.
Recommendation
It is recommended to immediately update the Linux kernel to a version containing the fix, which adds 'cond_resched' and 'touch_softlockup_watchdog' calls during task traversal in the OOM cgroup.
Other vulnerabilities in Linux kernel
See all- CVE-2026-98164Unknown
In the Linux kernel, KVM x86/mmu's kvm_gfn_is_write_tracked() only checks the supplied memslot, but page tracking is per-address-space and shadow pages are shared across address spaces. With SMM, a GFN can be write-tracked in one address space and appear untracked in another. The fix checks the supplied slot first, then the slot for the other address space, preventing mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and triggering a BUG in pte_list_remove().
- CVE-2026-98048Unknown
In the Linux kernel's BPF subsystem, mark_fastcall_pattern_for_call() must ensure that a matched "spill; call; fill" instruction series is not interrupted by a jump. Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills() is unsound. The fix records instructions targeted by jumps in insn_aux_data[*].jump_target and uses this flag to stop growing a pattern.
- CVE-2026-98047Unknown
In the Linux kernel's BPF subsystem, in_rbtree_lock_required_cb() only checks the innermost verifier frame, so rbtree callback restrictions disappear in a nested static subprogram call frame. The subprogram can unlock the tree, remove and drop the node being compared, then relock, leading to freed memory being linked into the tree.
- CVE-2026-98046Unknown
In the Linux kernel's BPF subsystem, bpf_btf_find_by_name_kind() returns a new BTF object fd through __btf_new_fd(), which reaches anon_inode_getfd() that can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks.
- CVE-2026-98045Unknown
In the Linux kernel, a BPF verifier vulnerability affects stack helpers that may block on filesystem reads (e.g., resolving build IDs) but were not marked as sleepable. The verifier could still allow these helpers from non-sleepable regions such as RCU or preemption-disabled sections.
- CVE-2026-98044Unknown
In the Linux kernel, the BPF verifier mishandled legacy packet-load instructions (BPF_LD_ABS/BPF_LD_IND) reached from callbacks, triggering a verifier bug warning and an -EFAULT on BPF_PROG_LOAD. A privileged program loader could trigger this issue.
- CVE-2026-98043Unknown
In the Linux kernel, the BPF verifier incorrectly inferred that a pointer with an unbounded offset is non-NULL based solely on its type. As a result, a BPF program could pass verification while a NULL pointer dereference occurred at runtime.
- CVE-2026-98042Unknown
In the Linux kernel, the BPF verifier could resurrect a scalar id dropped by collect_linked_regs() because snapshots of compared registers were taken before linked registers were collected. This could lead to range inconsistencies and precision propagation issues.
- CVE-2026-98041High
In the Linux kernel, the BPF verifier incorrectly predicted the outcome of pointer vs zero comparisons in JMP32 instructions, failing to distinguish BPF_JMP from BPF_JMP32 comparisons. This led to incorrect inference that a jump is always taken.
- CVE-2026-98040Unknown
In the Linux kernel, the BPF verifier did not mark the zero register as precise for a register-form NULL check. As a result, one path was pruned and the program could dereference a zero pointer at runtime.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

