{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-40949 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-40949 is a high-severity memory corruption vulnerability in Linux kernel, published on 12 Jul 2024. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2024-40949 and fix it if it is affected.\n\nWhat it is: CVE-2024-40949 is a high-severity memory corruption vulnerability in Linux kernel, published on 12 Jul 2024. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2024-40949 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2024-40949/ (Markdown: https://insights.sbomify.com/CVE-2024-40949/index.md)","id":"CVE-2024-40949","markdown":"https://insights.sbomify.com/CVE-2024-40949/index.md","name":"CVE-2024-40949","record":{"aliases":["BELL-CVE-2024-40949","DEBIAN-CVE-2024-40949","GHSA-c3vj-49c5-5wp9","UBUNTU-CVE-2024-40949"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A flaw in the Linux kernel's shmem handling can cause LRU list crashes and incorrect statistics, leading to system instability or denial of service.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm: shmem: fix getting incorrect lruvec when replacing a shmem folio\n\nWhen testing shmem swapin, I encountered the warning below on my machine. \nThe reason is that replacing an old shmem folio with a new one causes\nmem_cgroup_migrate() to clear the old folio's memcg data.  As a result,\nthe old folio cannot get the correct memcg's lruvec needed to remove\nitself from the LRU list when it is being freed.  This could lead to\npossible serious problems, such as LRU list crashes due to holding the\nwrong LRU lock, and incorrect LRU statistics.\n\nTo fix this issue, we can fallback to use the mem_cgroup_replace_folio()\nto replace the old shmem folio.\n\n[ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960\n[ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n[ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff)\n[ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000\n[ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000\n[ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000\n[ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg \u0026\u0026 !mem_cgroup_disabled())\n[ 5241.100338] ------------[ cut here ]------------\n[ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150\n[...]\n[ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150\n[ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150\n[ 5241.100376] sp : ffff80008b38b930\n[...]\n[ 5241.100398] Call trace:\n[ 5241.100399]  folio_lruvec_lock_irqsave+0x140/0x150\n[ 5241.100401]  __page_cache_release+0x90/0x300\n[ 5241.100404]  __folio_put+0x50/0x108\n[ 5241.100406]  shmem_replace_folio+0x1b4/0x240\n[ 5241.100409]  shmem_swapin_folio+0x314/0x528\n[ 5241.100411]  shmem_get_folio_gfp+0x3b4/0x930\n[ 5241.100412]  shmem_fault+0x74/0x160\n[ 5241.100414]  __do_fault+0x40/0x218\n[ 5241.100417]  do_shared_fault+0x34/0x1b0\n[ 5241.100419]  do_fault+0x40/0x168\n[ 5241.100420]  handle_pte_fault+0x80/0x228\n[ 5241.100422]  __handle_mm_fault+0x1c4/0x440\n[ 5241.100424]  handle_mm_fault+0x60/0x1f0\n[ 5241.100426]  do_page_fault+0x120/0x488\n[ 5241.100429]  do_translation_fault+0x4c/0x68\n[ 5241.100431]  do_mem_abort+0x48/0xa0\n[ 5241.100434]  el0_da+0x38/0xc0\n[ 5241.100436]  el0t_64_sync_handler+0x68/0xc0\n[ 5241.100437]  el0t_64_sync+0x14c/0x150\n[ 5241.100439] ---[ end trace 0000000000000000 ]---\n\n[baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew]","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"mm: shmem: fix getting incorrect lruvec when replacing a shmem folio","id":"CVE-2024-40949","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"memory_corruption","year":"2024"},"n_packages":0,"n_references":2,"next":{"headline":"mm: huge_memory: fix misused mapping_large_folio_support() for anon folios","id":"CVE-2024-40950"},"packages":[],"prev":{"headline":"mm/page_table_check: fix crash on ZONE_DEVICE","id":"CVE-2024-40948"},"products":["Linux"],"published":"2024-07-12","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A flaw in the Linux kernel's shmem handling can cause LRU list crashes and incorrect statistics, leading to system instability or denial of service.","url":"https://insights.sbomify.com/CVE-2024-40949/"}