CVE-2024-40914 in Linux
Summary
by MITRE • 07/12/2024
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: don't unpoison huge_zero_folio
When I did memory failure tests recently, below panic occurs:
kernel BUG at include/linux/mm.h:1135! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0 Call Trace: do_shrink_slab+0x14f/0x6a0 shrink_slab+0xca/0x8c0 shrink_node+0x2d0/0x7d0 balance_pgdat+0x33a/0x720 kswapd+0x1f3/0x410 kthread+0xd5/0x100 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 Modules linked in: mce_inject hwpoison_inject ---[ end trace 0000000000000000 ]---
RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0
The root cause is that HWPoison flag will be set for huge_zero_folio without increasing the folio refcnt. But then unpoison_memory() will decrease the folio refcnt unexpectedly as it appears like a successfully hwpoisoned folio leading to VM_BUG_ON_PAGE(page_ref_count(page) == 0) when releasing huge_zero_folio.
Skip unpoisoning huge_zero_folio in unpoison_memory() to fix this issue. We're not prepared to unpoison huge_zero_folio yet.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2025
The vulnerability described in CVE-2024-40914 resides within the Linux kernel's memory management subsystem, specifically in the huge memory handling mechanisms. This issue manifests as a kernel panic during memory failure testing scenarios, where the system encounters an invalid opcode exception and subsequently crashes. The problem occurs during the execution of the shrink_huge_zero_page_scan function, which is part of the memory management subsystem's efforts to reclaim memory from huge zero pages. The crash trace indicates that the kernel is attempting to access memory that has been corrupted or improperly handled, leading to a system-wide failure. The root cause stems from an improper handling of the HWPoison flag for huge_zero_folio objects, which are special memory pages used in huge page implementations. When memory failure tests are conducted, the system sets the HWPoison flag on these pages without properly incrementing their reference count. This creates a scenario where the memory management subsystem incorrectly treats these pages as successfully poisoned, leading to unexpected reference count decrements during the unpoisoning process.
The technical flaw involves a race condition and improper reference counting mechanism within the kernel's memory management code. The huge_zero_folio objects are designed to be zero-filled pages that can be shared across multiple processes, but when memory failure occurs, the system attempts to handle these pages through the hwpoison mechanism. The kernel's unpoison_memory() function incorrectly processes these huge zero folios by attempting to decrease their reference count, even though they were never properly reference-counted during the initial poisoning operation. This discrepancy causes a critical condition where the page reference count drops to zero, triggering the VM_BUG_ON_PAGE assertion that protects against invalid memory operations. The vulnerability is classified under CWE-129 as an Improper Validation of Array Index, though it more accurately represents a reference counting error that leads to memory corruption. The improper handling of these specific memory objects creates a path where the kernel's memory subsystem can be forced into an inconsistent state that results in immediate system termination.
The operational impact of this vulnerability is severe as it can cause complete system crashes during memory failure testing or under memory pressure conditions. The panic occurs specifically when the kernel's memory reclaim daemon kswapd attempts to process huge zero pages during memory pressure situations, making this a critical issue for systems that rely heavily on memory management and virtualization. Systems running with memory failure testing enabled or those experiencing memory pressure during high workloads are particularly vulnerable to this issue. The vulnerability essentially creates a denial of service condition where the kernel becomes unstable and crashes when attempting to handle memory failure scenarios involving huge pages. This affects not only the stability of individual systems but also the reliability of memory-intensive applications and virtualized environments that utilize huge page memory management. The issue is particularly concerning for server environments, cloud computing platforms, and systems that require robust memory management capabilities under stress conditions.
The mitigation strategy for this vulnerability involves modifying the unpoison_memory() function to explicitly skip the processing of huge_zero_folio objects, preventing the incorrect reference count operations that lead to the kernel panic. This approach aligns with the established ATT&CK framework's mitigation techniques for kernel-level vulnerabilities by addressing the root cause rather than attempting to patch symptoms. The fix implements a targeted approach that specifically excludes huge zero folios from the unpoisoning process, acknowledging that the system is not yet prepared to handle the unpoisoning of these specific memory objects. This solution maintains system stability while preventing the crash condition, though it does require careful consideration of the memory management implications for systems that might rely on such unpoisoning operations in the future. Organizations should apply this patch immediately to systems that perform memory failure testing or operate under high memory pressure conditions, as the vulnerability can lead to complete system instability and data loss during memory management operations. The fix represents a defensive programming approach that prevents invalid memory operations while preserving the overall functionality of the memory management subsystem.