CVE-2024-40949: mm: shmem: fix getting incorrect lruvec when replacing a shmem folio
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 ]---
[baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew]
Security readout for executives and security teams
Plain-English summary
A Linux kernel memory-management flaw can select the wrong memory-control LRU data and lock while replacing shared-memory pages during swap-in. This may cause kernel warnings, LRU list crashes, or incorrect memory statistics. The CVSS assessment rates potential confidentiality, integrity, and availability impact high, but the supplied sources do not establish a practical exploit.
Executive priority
Treat this as a high-priority kernel remediation, especially for multi-user Linux hosts or systems running untrusted local workloads. Inventory affected kernels promptly and deploy verified vendor backports during an urgent maintenance window. The supplied evidence does not justify declaring active compromise solely because a vulnerable version is present.
Technical view
During shmem folio replacement, mem_cgroup_migrate() clears the old folio’s memory-cgroup data before LRU removal. The kernel may therefore obtain an incorrect lruvec and hold the wrong LRU lock while freeing the folio. The referenced fix replaces this behavior with mem_cgroup_replace_folio().
Likely exposure
Exposure is limited to affected Linux kernels and requires local access according to the CVSS vector. Multi-user systems and hosts running untrusted local workloads deserve particular attention. The supplied version data includes Linux 6.7, 6.9.7, and 6.10-related entries, but distributors may backport fixes, so version strings alone are insufficient.
Exploitation context
The CVSS vector describes a low-complexity, low-privilege local attack requiring no user interaction. CISA KEV status is false, and the supplied sources provide no evidence of active exploitation or a public exploit. They document a warning observed during shmem swap-in testing and potentially serious kernel consequences.
Researcher notes
The reported failure path runs through shmem_replace_folio(), shmem_swapin_folio(), and folio_lruvec_lock_irqsave(). Evidence supports incorrect locking, possible LRU list crashes, and inaccurate statistics. No CWE is supplied, and the sources do not demonstrate reliable exploitation, privilege escalation, or the conditions needed to realize the CVSS confidentiality and integrity impacts.
Mitigation direction
Apply a vendor kernel update containing one of the referenced stable fixes.
Check distribution advisories for backport status because package versions may differ from upstream releases.
Prioritize multi-user systems and hosts that execute untrusted local workloads.
Reboot updated systems when required to activate the corrected kernel.
Validation and detection
Inventory running kernel versions across Linux systems and compare them with vendor advisories.
Confirm the installed kernel includes a referenced fix or documented vendor backport.
Review kernel logs for folio_lruvec_lock_irqsave warnings and related shmem swap-in traces.
After remediation, confirm systems are running the updated kernel and monitor for recurrence.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-40949 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.