https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Wed, 27 May 2026 20:54:11 +0000 https://vulnerability.circl.lu/sighting/d479175f-8cbd-44cf-98d7-dce77477ebd5/export {"uuid": "d479175f-8cbd-44cf-98d7-dce77477ebd5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45022", "type": "seen", "source": "https://t.me/cvedetector/5378", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-45022 - Linux Kernel VMware Mapping Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-45022 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nmm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 \n \nThe __vmap_pages_range_noflush() assumes its argument pages** contains \npages with the same page shift. However, since commit e9c3cda4d86e (\"mm, \nvmalloc: fix high order __GFP_NOFAIL allocations\"), if gfp_flags includes \n__GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation \nfailed for high order, the pages** may contain two different page shifts \n(high order and order-0). This could lead __vmap_pages_range_noflush() to \nperform incorrect mappings, potentially resulting in memory corruption. \n \nUsers might encounter this as follows (vmap_allow_huge = true, 2M is for \nPMD_SIZE): \n \nkvmalloc(2M, __GFP_NOFAIL|GFP_X) \n __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) \n vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0 \n vmap_pages_range() \n vmap_pages_range_noflush() \n __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens \n \nWe can remove the fallback code because if a high-order allocation fails, \n__vmalloc_node_range_noprof() will retry with order-0. Therefore, it is \nunnecessary to fallback to order-0 here. Therefore, fix this by removing \nthe fallback code. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"11 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:35.000000Z"} {"uuid": "d479175f-8cbd-44cf-98d7-dce77477ebd5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45022", "type": "seen", "source": "https://t.me/cvedetector/5378", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-45022 - Linux Kernel VMware Mapping Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-45022 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nmm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 \n \nThe __vmap_pages_range_noflush() assumes its argument pages** contains \npages with the same page shift. However, since commit e9c3cda4d86e (\"mm, \nvmalloc: fix high order __GFP_NOFAIL allocations\"), if gfp_flags includes \n__GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation \nfailed for high order, the pages** may contain two different page shifts \n(high order and order-0). This could lead __vmap_pages_range_noflush() to \nperform incorrect mappings, potentially resulting in memory corruption. \n \nUsers might encounter this as follows (vmap_allow_huge = true, 2M is for \nPMD_SIZE): \n \nkvmalloc(2M, __GFP_NOFAIL|GFP_X) \n __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) \n vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0 \n vmap_pages_range() \n vmap_pages_range_noflush() \n __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens \n \nWe can remove the fallback code because if a high-order allocation fails, \n__vmalloc_node_range_noprof() will retry with order-0. Therefore, it is \nunnecessary to fallback to order-0 here. Therefore, fix this by removing \nthe fallback code. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"11 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:35.000000Z"} https://vulnerability.circl.lu/sighting/d479175f-8cbd-44cf-98d7-dce77477ebd5/export Wed, 11 Sep 2024 18:41:35 +0000