CVE-2024-26987 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted ------------------------------------------------------ bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:
__mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1 ---- ---- lock(pcp_batch_high_lock); lock(cpu_hotplug_lock); lock(pcp_batch_high_lock); rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
#1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0
#2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0
#3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70
#4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace: CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00
In short, below scene breaks the ---truncated---
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/06/2026
The vulnerability CVE-2024-26987 addresses a critical deadlock condition within the Linux kernel's memory management subsystem, specifically when handling huge page memory failures in conjunction with the hugetlb_optimize_vmemmap feature. This issue manifests during hard offline memory operations involving huge pages, where a circular locking dependency is triggered between the cpu_hotplug_lock and pcp_batch_high_lock. The deadlock occurs when the kernel attempts to process memory failure events while simultaneously managing CPU hotplug operations and huge page memory mappings. The root cause lies in the improper acquisition order of locks during the memory failure handling process, where the system tries to acquire a lock that is already held by the same task, creating a circular dependency that halts system progress.
The technical flaw stems from the interaction between multiple kernel subsystems including the memory failure handler, huge page management, and CPU hotplug infrastructure. When a memory failure is detected on a huge page, the kernel invokes the memory_failure function which eventually calls __hugetlb_vmemmap_restore_folio. This function attempts to decrement a static key while holding the pcp_batch_high_lock, but the static_key_slow_dec function requires acquiring the cpu_hotplug_lock. However, the cpu_hotplug_lock is already held by the same execution context due to ongoing CPU hotplug operations, resulting in a circular dependency. The ATT&CK framework would categorize this as a system-level privilege escalation vector through denial of service, as the deadlock prevents normal system operation and can be triggered remotely via memory failure injection.
The operational impact of this vulnerability is severe, as it can cause complete system hangs or crashes during memory failure scenarios, particularly in high-performance computing environments that rely heavily on huge pages for memory management. Systems using huge page optimizations for database servers, virtualization platforms, or real-time applications are especially vulnerable, as these environments frequently trigger memory failure events during stress testing or hardware degradation. The vulnerability affects any Linux kernel version that has the hugetlb_optimize_vmemmap feature enabled, making it a widespread concern across production environments where memory reliability and system stability are critical. The deadlock prevents system recovery and can lead to complete service outages until manual intervention or system reboot occurs.
Mitigation strategies for CVE-2024-26987 include disabling the hugetlb_optimize_vmemmap feature through kernel boot parameters or sysctl settings to prevent the problematic code path from being executed. System administrators should also apply the latest kernel patches that contain the fix for this deadlock condition, which typically involves reordering lock acquisitions or introducing additional synchronization mechanisms to break the circular dependency. Monitoring systems should be enhanced to detect early signs of lock contention, as the deadlock may manifest as system unresponsiveness or memory failure handling delays. Organizations using virtualization technologies should ensure that their hypervisor and guest kernel versions are updated to avoid triggering this condition during memory failure scenarios. The fix aligns with CWE-362, which addresses concurrent execution issues through improper locking, and represents a critical kernel-level security patch that should be prioritized in all production environments.