{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-49878 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-49878 is a medium-severity vulnerability in Linux kernel, published on 21 Oct 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-49878 and fix it if it is affected.\n\nWhat it is: CVE-2024-49878 is a medium-severity vulnerability in Linux kernel, published on 21 Oct 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-49878 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-49878/ (Markdown: https://insights.sbomify.com/CVE-2024-49878/index.md)","id":"CVE-2024-49878","markdown":"https://insights.sbomify.com/CVE-2024-49878/index.md","name":"CVE-2024-49878","record":{"aliases":["AZL-52929","BELL-CVE-2024-49878","DEBIAN-CVE-2024-49878","GHSA-f3xx-63r9-v2cp","UBUNTU-CVE-2024-49878"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["security_bypass"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A logic error in Linux kernel CXL memory handling bypasses /dev/mem permission checks, potentially allowing unauthorized memory access attempts.","user_interaction":"not_required","vuln_class":"security_feature_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nresource: fix region_intersects() vs add_memory_driver_managed()\n\nOn a system with CXL memory, the resource tree (/proc/iomem) related to\nCXL memory may look like something as follows.\n\n490000000-50fffffff : CXL Window 0\n  490000000-50fffffff : region0\n    490000000-50fffffff : dax0.0\n      490000000-50fffffff : System RAM (kmem)\n\nBecause drivers/dax/kmem.c calls add_memory_driver_managed() during\nonlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL\nWindow X\".  This confuses region_intersects(), which expects all \"System\nRAM\" resources to be at the top level of iomem_resource.  This can lead to\nbugs.\n\nFor example, when the following command line is executed to write some\nmemory in CXL memory range via /dev/mem,\n\n $ dd if=data of=/dev/mem bs=$((1 \u003c\u003c 10)) seek=$((0x490000000 \u003e\u003e 10)) count=1\n dd: error writing '/dev/mem': Bad address\n 1+0 records in\n 0+0 records out\n 0 bytes copied, 0.0283507 s, 0.0 kB/s\n\nthe command fails as expected.  However, the error code is wrong.  It\nshould be \"Operation not permitted\" instead of \"Bad address\".  More\nseriously, the /dev/mem permission checking in devmem_is_allowed() passes\nincorrectly.  Although the accessing is prevented later because ioremap()\nisn't allowed to map system RAM, it is a potential security issue.  During\ncommand executing, the following warning is reported in the kernel log for\ncalling ioremap() on system RAM.\n\n ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff\n WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d\n Call Trace:\n  memremap+0xcb/0x184\n  xlate_dev_mem_ptr+0x25/0x2f\n  write_mem+0x94/0xfb\n  vfs_write+0x128/0x26d\n  ksys_write+0xac/0xfe\n  do_syscall_64+0x9a/0xfd\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe details of command execution process are as follows.  In the above\nresource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a\ntop level resource.  So, region_intersects() will report no System RAM\nresources in the CXL memory region incorrectly, because it only checks the\ntop level resources.  Consequently, devmem_is_allowed() will return 1\n(allow access via /dev/mem) for CXL memory region incorrectly. \nFortunately, ioremap() doesn't allow to map System RAM and reject the\naccess.\n\nSo, region_intersects() needs to be fixed to work correctly with the\nresource tree with \"System RAM\" not at top level as above.  To fix it, if\nwe found a unmatched resource in the top level, we will continue to search\nmatched resources in its descendant resources.  So, we will not miss any\nmatched resources in resource tree anymore.\n\nIn the new implementation, an example resource tree\n\n|------------- \"CXL Window 0\" ------------|\n|-- \"System RAM\" --|\n\nwill behave similar as the following fake resource tree for\nregion_intersects(, IORESOURCE_SYSTEM_RAM, ),\n\n|-- \"System RAM\" --||-- \"CXL Window 0a\" --|\n\nWhere \"CXL Window 0a\" is part of the original \"CXL Window 0\" that\nisn't covered by \"System RAM\".","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":"resource: fix region_intersects() vs add_memory_driver_managed()","id":"CVE-2024-49878","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"security_feature_bypass","year":"2024"},"n_packages":0,"n_references":8,"next":{"headline":"drm: omapdrm: Add missing check for alloc_ordered_workqueue","id":"CVE-2024-49879"},"packages":[],"prev":{"headline":"ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate","id":"CVE-2024-49877"},"products":["Linux"],"published":"2024-10-21","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-05-11","vendors":["Linux"]},"summary":"A logic error in Linux kernel CXL memory handling bypasses /dev/mem permission checks, potentially allowing unauthorized memory access attempts.","url":"https://insights.sbomify.com/CVE-2024-49878/"}