{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-04-20T19:57:30.311","vulnerabilities":[{"cve":{"id":"CVE-2024-45022","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2024-09-11T16:15:07.163","lastModified":"2025-11-03T23:15:50.313","vulnStatus":"Modified","cveTags":[],"descriptions":[{"lang":"en","value":"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."},{"lang":"es","value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: se corrige la asignación de páginas si vm_area_alloc_pages() con un retroceso de orden superior al orden 0 __vmap_pages_range_noflush() asume que su argumento pages** contiene páginas con el mismo cambio de página. Sin embargo, desde el commit e9c3cda4d86e (\"mm, vmalloc: se corrigen las asignaciones de orden superior __GFP_NOFAIL\"), si gfp_flags incluye __GFP_NOFAIL con orden superior en vm_area_alloc_pages() y la asignación de páginas falla para el orden superior, pages** puede contener dos cambios de página diferentes (orden superior y orden 0). Esto podría provocar que __vmap_pages_range_noflush() realice asignaciones incorrectas, lo que podría provocar una corrupción de memoria. Los usuarios pueden encontrarse con esto de la siguiente manera (vmap_allow_huge = true, 2M es para PMD_SIZE): kvmalloc(2M, __GFP_NOFAIL|GFP_X) __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) vm_area_alloc_pages(order=9) ---> la asignación del pedido 9 falló y se vuelve al pedido 0 vmap_pages_range() vmap_pages_range_noflush() __vmap_pages_range_noflush(page_shift = 21) ----> ocurre una asignación incorrecta Podemos eliminar el código de respaldo porque si falla una asignación de orden alto, __vmalloc_node_range_noprof() volverá a intentarlo con el pedido 0. Por lo tanto, no es necesario volver al pedido 0 aquí. Por lo tanto, solucione esto eliminando el código de respaldo."}],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"CWE-787"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.1.95","versionEndExcluding":"6.1.107","matchCriteriaId":"EAB88E73-4A4D-4E7B-B85E-47EA47174A83"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.3","versionEndExcluding":"6.6.48","matchCriteriaId":"8A7B36D8-72F7-4F2A-A151-A59474D95B61"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.7","versionEndExcluding":"6.10.7","matchCriteriaId":"D2AFDFD1-D95A-4EB7-843B-5E7659518B67"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*","matchCriteriaId":"8B3CE743-2126-47A3-8B7C-822B502CF119"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*","matchCriteriaId":"4DEB27E7-30AA-45CC-8934-B89263EF3551"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.11:rc3:*:*:*:*:*:*","matchCriteriaId":"E0005AEF-856E-47EB-BFE4-90C46899394D"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/61ebe5a747da649057c37be1c37eb934b4af79ca","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/c91618816f4d21fc574d7577a37722adcd4075b2","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/de7bad86345c43cd040ed43e20d9fad78a3ee59f","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/fd1ffbb50ef4da5e1378a46616b6d7407dc795da","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html","source":"af854a3a-2127-422b-91ae-364da2661108"}]}}]}