CVE-2024-40949 in Linux
Summary
by MITRE • 07/12/2024
In the Linux kernel, the following vulnerability has been resolved:
mm: shmem: fix getting incorrect lruvec when replacing a shmem folio
When testing shmem swapin, I encountered the warning below on my machine. The reason is that replacing an old shmem folio with a new one causes mem_cgroup_migrate() to clear the old folio's memcg data. As a result, the old folio cannot get the correct memcg's lruvec needed to remove itself from the LRU list when it is being freed. This could lead to possible serious problems, such as LRU list crashes due to holding the wrong LRU lock, and incorrect LRU statistics.
To fix this issue, we can fallback to use the mem_cgroup_replace_folio() to replace the old shmem folio.
[ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960
[ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff)
[ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000
[ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000
[ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000
[ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000
[ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled())
[ 5241.100338] ------------[ cut here ]------------
[ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150
[...]
[ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150
[ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150
[ 5241.100376] sp : ffff80008b38b930
[...]
[ 5241.100398] Call trace:
[ 5241.100399] folio_lruvec_lock_irqsave+0x140/0x150
[ 5241.100401] __page_cache_release+0x90/0x300
[ 5241.100404] __folio_put+0x50/0x108
[ 5241.100406] shmem_replace_folio+0x1b4/0x240
[ 5241.100409] shmem_swapin_folio+0x314/0x528
[ 5241.100411] shmem_get_folio_gfp+0x3b4/0x930
[ 5241.100412] shmem_fault+0x74/0x160
[ 5241.100414] __do_fault+0x40/0x218
[ 5241.100417] do_shared_fault+0x34/0x1b0
[ 5241.100419] do_fault+0x40/0x168
[ 5241.100420] handle_pte_fault+0x80/0x228
[ 5241.100422] __handle_mm_fault+0x1c4/0x440
[ 5241.100424] handle_mm_fault+0x60/0x1f0
[ 5241.100426] do_page_fault+0x120/0x488
[ 5241.100429] do_translation_fault+0x4c/0x68
[ 5241.100431] do_mem_abort+0x48/0xa0
[ 5241.100434] el0_da+0x38/0xc0
[ 5241.100436] el0t_64_sync_handler+0x68/0xc0
[ 5241.100437] el0t_64_sync+0x14c/0x150
[ 5241.100439] ---[ end trace 0000000000000000 ]---
[[email protected]: remove less helpful comments, per Matthew]
Link: https://lkml.kernel.org/r/ccad3fe1375b468ebca3227b6b729f3eaf9d8046.1718423197.git.baolin.wang@linux.alibaba.com
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2025
The vulnerability described in CVE-2024-40949 resides within the Linux kernel's memory management subsystem, specifically in the shared memory (shmem) implementation. This flaw manifests during the process of swapping in shmem folios, where the kernel attempts to replace an existing folio with a new one. The issue arises from an improper handling of memory control group (memcg) data during this replacement operation, leading to critical inconsistencies in the management of memory allocation and tracking.
The technical root cause involves the mem_cgroup_migrate() function which clears the memory control group data from the old folio during replacement. This action leaves the old folio without the necessary memcg context required to correctly locate and access its respective lruvec (least recently used vector) when it is eventually freed. The lruvec is essential for proper LRU list management and lock handling, and without it, the kernel may attempt to acquire locks on incorrect data structures or access invalid memory regions.
When the old folio attempts to release itself, it triggers a warning and subsequently a kernel panic due to the VM_WARN_ON_ONCE_FOLIO assertion failure. The call trace reveals that the error originates from folio_lruvec_lock_irqsave(), indicating that the kernel is trying to lock an LRU vector that does not correspond to the correct memory control group. This misalignment leads to potential LRU list corruption, which can result in system instability or crashes.
This vulnerability directly maps to CWE-121, which deals with stack-based buffer overflow, and more specifically to CWE-129, concerning improper validation of array indices. The issue also aligns with ATT&CK technique T1490, which involves data destruction through manipulation of memory management components. The improper handling of memory control group references during folio replacement creates a condition where system memory integrity is compromised, potentially allowing for privilege escalation or denial of service attacks.
The fix implemented addresses this by falling back to using mem_cgroup_replace_folio() for replacing old shmem folios. This approach ensures that the memory control group information is properly maintained throughout the replacement process, preventing the loss of lruvec references. The solution maintains the integrity of memory management operations while preserving the expected behavior of shmem swapin functionality.
This vulnerability demonstrates the complexity of memory management in modern operating systems where multiple subsystems must coordinate properly to maintain system stability. The interaction between memory control groups, LRU management, and folio replacement mechanisms requires careful synchronization to prevent such race conditions and data corruption scenarios. The fix represents a defensive programming approach that preserves the integrity of memory management data structures during critical operations, ensuring that kernel subsystems can safely operate without corrupting shared data structures.
The impact of this vulnerability extends beyond simple memory management issues, as incorrect LRU list handling can affect system performance and stability. When LRU lists become corrupted, the kernel's ability to efficiently manage memory pages is compromised, potentially leading to increased memory pressure, degraded performance, or complete system crashes. The warning messages and kernel panic indicate that this is not a benign issue but one that can severely impact system reliability and availability. The vulnerability highlights the importance of maintaining proper reference counting and data structure consistency in kernel memory management code, where even seemingly minor operations can have cascading effects on system stability.