CVE-2026-74672
Full vulnerability record from the local CVENow database.
Description
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable freeing", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), which this series has to deal with carefully. This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch. There are related issues that are also addressed in this series: * x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked. The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA fixes are in place). This patch (of 3): Currently there is a nasty ra ---truncated---
View original CVE JSON
{
"id": "CVE-2026-74672",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2026-08-22T16:16:41.200",
"lastModified": "2026-10-30T13:20:03.407",
"vulnStatus": "Received",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF\n\nPatch series \"mm: fix UAF caused by race between ptdump and vmap pgtable\nfreeing\", v6.\n\nKernel page table walkers fall into two broad categories - those ranges\nwhere no exclusion is required via walk_kernel_page_table_range_lockless()\nand those where exclusion is required via walk_kernel_page_table_range()\nor walk_page_range_debug().\n\nThe former category is used only by arm64 arch code operating on ranges it\nboth wholly owns and does not concurrently write.\n\nThe latter category consists of kernel page table walkers operating on\nranges that are wholly owned (but which need exclusion against concurrent\nwriters).\n\nThe lock used for exclusion is the mmap lock, and for kernel ranges this\nis the mmap lock on init_mm.\n\nptdump is a special case being both the only user of\nwalk_page_range_debug(), and the only case in which it walks ranges it\ndoes not own.\n\nThis presents a problem, as page tables may be freed under ptdump. And\nindeed there is a use-after-free bug in the kernel as a result, which this\nseries addresses.\n\nvmap promotes page tables to huge leaf entries where possible, freeing the\nlower page table when it does. It does this with no meaningful locks held\nagainst concurrent ptdump walks.\n\nAs a result, use-after-free can currently occur. This series addresses\nthe issue by having the vmap huge promotion logic acquire the mmap read\nlock while both setting the huge page table entry and freeing the prior\nleaf page table.\n\nThe ptdump code already acquires the mmap write lock, so by doing so we\nensure that the ptdump walker only ever observes either the huge page\ntable entry or the existing page table entry, and nothing is freed\nunderneath it.\n\nA mitigation for this issue was already applied for arm64 in commit\nfa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), which this series\nhas to deal with carefully.\n\nThis mitigation resolves the issue by acquiring the mmap read lock on\ninit_mm on vmap page table free if a ptdump is in progress.\n\nHowever the fix in this series would cause a deadlock if we were to simply\napply it for arm64 without also reverting the change.\n\nThis is because vmap may acquire the read lock before ptdump attempts to\nacquire the write lock, which then gets queued, and rwsem starvation rules\nmean that the (unacknowledged) nested mmap read lock in the arm64 code\nwould also block, meaning the original read lock is never released and\nthus deadlock.\n\nThis series works around this by #ifndef CONFIG_ARM64'ing the mmap read\nlock in vmap logic, then partially reverting commit fa93b45fd397 (\"arm64:\nEnable vmalloc-huge with ptdump\"), keeping the enablement of huge vmap\nsupport, and removing the ifdeffery with the partial revert patch.\n\nThere are related issues that are also addressed in this series:\n\n* x86 page attribute logic, specifically Change Page Attributes (CPA),\n implements a feature whereby huge ranges can be collapsed into huge leaf\n entries. This can similarly cause a UAF when done in parallel with a\n ptdump walk, so similarly acquire the init_mm mmap lock to avoid this.\n\n* The CPA logic allows concurrent page table manipulation and CPA\n collapse, meaning the former risks accessing a page table the latter\n frees. Fix this by acquiring mmap write lock on init_mm across the\n whole CPA collapse operation and read lock on the page table\n manipulation.\n\n* x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm\n walks, and in x86's case arbitrary mm's), so we ensure kernel mappings\n remain stable by locking the init_mm as well as the mm being walked.\n\nThe ordering of patches is established for both strict dependencies (the\narm64 partial revert in particular has to be done after the vmap changes)\nand logical ones (the non-kernel mm fix only makes sense once the vmap/CPA\nfixes are in place).\n\n\nThis patch (of 3):\n\nCurrently there is a nasty ra\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nmm/vmalloc: adquirir el bloqueo init_mm en vmap enorme para evitar el uso después de liberación de ptdump\n\nSerie de parches “mm: corregir el uso después de liberación causado por la condición de carrera entre ptdump y la liberación de la tabla de páginas vmap”, v6.\n\nLos recorredores de tablas de páginas del kernel se dividen en dos categorías amplias: aquellos rangos donde no se requiere exclusión a través de walk_kernel_page_table_range_lockless() y aquellos donde se requiere exclusión a través de walk_kernel_page_table_range() o walk_page_range_debug().\n\nLa primera categoría es utilizada solo por el código de arquitectura arm64 que opera en rangos que posee completamente y no escribe concurrentemente.\n\nLa última categoría consiste en recorredores de tablas de páginas del kernel que operan en rangos que son de propiedad total (pero que necesitan exclusión contra escritores concurrentes).\n\nEl bloqueo utilizado para la exclusión es el bloqueo mmap, y para los rangos del kernel, este es el bloqueo mmap en init_mm.\n\nptdump es un caso especial, siendo tanto el único usuario de walk_page_range_debug() como el único caso en el que recorre rangos que no posee.\n\nEsto presenta un problema, ya que las tablas de páginas pueden ser liberadas bajo ptdump. Y de hecho, existe un error de uso después de liberación en el kernel como resultado, que esta serie aborda.\n\nvmap promueve las tablas de páginas a entradas de hoja enormes cuando es posible, liberando la tabla de páginas inferior cuando lo hace. Lo hace sin bloqueos significativos mantenidos contra recorridos ptdump concurrentes.\n\nComo resultado, el uso después de liberación puede ocurrir actualmente. Esta serie aborda el problema haciendo que la lógica de promoción enorme de vmap adquiera el bloqueo de lectura mmap mientras establece la entrada de la tabla de páginas enorme y libera la tabla de páginas de hoja anterior.\n\nEl código ptdump ya adquiere el bloqueo de escritura mmap, por lo que al hacerlo nos aseguramos de que el recorredor ptdump solo observe la entrada de la tabla de páginas enorme o la entrada de la tabla de páginas existente, y nada se libera debajo de ella.\n\nUna mitigación para este problema ya se aplicó para arm64 en el commit fa93b45fd397 ('arm64: Habilitar vmalloc-huge con ptdump'), con la que esta serie tiene que lidiar con cuidado.\n\nEsta mitigación resuelve el problema adquiriendo el bloqueo de lectura mmap en init_mm en la liberación de la tabla de páginas vmap si un ptdump está en curso.\n\nSin embargo, la corrección en esta serie causaría un interbloqueo si simplemente la aplicáramos para arm64 sin revertir también el cambio.\n\nEsto se debe a que vmap puede adquirir el bloqueo de lectura antes de que ptdump intente adquirir el bloqueo de escritura, que luego se pone en cola, y las reglas de inanición de rwsem significan que el bloqueo de lectura mmap anidado (no reconocido) en el código arm64 también se bloquearía, lo que significa que el bloqueo de lectura original nunca se libera y, por lo tanto, se produce un interbloqueo.\n\nEsta serie soluciona esto mediante el uso de #ifndef CONFIG_ARM64 para el bloqueo de lectura mmap en la lógica de vmap, luego revirtiendo parcialmente el commit fa93b45fd397 ('arm64: Habilitar vmalloc-huge con ptdump'), manteniendo la habilitación del soporte de vmap enorme y eliminando la lógica ifdef con el parche de reversión parcial.\n\nHay problemas relacionados que también se abordan en esta serie:\n\n* La lógica de atributos de página x86, específicamente Cambio de Atributos de Página (CPA), implementa una característica mediante la cual los rangos enormes pueden colapsarse en entradas de hoja enormes. Esto puede causar de manera similar un uso después de liberación cuando se realiza en paralelo con un recorrido ptdump, por lo que de manera similar se adquiere el bloqueo mmap de init_mm para evitar esto.\n\n* La lógica CPA permite la manipulación concurrente de tablas de páginas y el colapso CPA, lo que significa que la primera corre el --TRUNCADO--"
}
],
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"include/linux/mmap_lock.h",
"mm/pagewalk.c",
"mm/vmalloc.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e",
"lessThan": "51eaba47b3dc258d1182fc3a88da544ed6b6bb2d",
"versionType": "git",
"status": "affected"
},
{
"version": "b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e",
"lessThan": "e85ed734611616d4a9d8a240bde563dd6ac7452f",
"versionType": "git",
"status": "affected"
},
{
"version": "b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e",
"lessThan": "39c6772b56a6bbdd62794833f74232971d94d7c9",
"versionType": "git",
"status": "affected"
},
{
"version": "b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e",
"lessThan": "8d7f560f4b0482d469de962fbe4b59c37561052e",
"versionType": "git",
"status": "affected"
},
{
"version": "b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e",
"lessThan": "7ac8a333dd41ba5e1b4e8c6edbc48b15446c5468",
"versionType": "git",
"status": "affected"
},
{
"version": "b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e",
"lessThan": "c5bf8cd148cfea948cfa3db71da427294b20db0f",
"versionType": "git",
"status": "affected"
},
{
"version": "b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e",
"lessThan": "3cc26c8907db0f5d1ff8043b5851ee572e9b3c98",
"versionType": "git",
"status": "affected"
},
{
"version": "b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e",
"lessThan": "26444eb71465c9934d9d418ef69c43f61185329b",
"versionType": "git",
"status": "affected"
},
{
"version": "31895cfd79564111cdd5a9f48c5d491ae26a238e",
"versionType": "git",
"status": "affected"
},
{
"version": "9c7f7bdb1932f8c1e5f80d32c717184701afe701",
"versionType": "git",
"status": "affected"
},
{
"version": "acdb4981644c8e31ccee294bdefff475c0cf587b",
"versionType": "git",
"status": "affected"
},
{
"version": "0454e2fad9306961540ee7e84da47a8e345b7d22",
"versionType": "git",
"status": "affected"
},
{
"version": "4.4.125",
"lessThan": "4.5",
"versionType": "semver",
"status": "affected"
},
{
"version": "4.9.91",
"lessThan": "4.10",
"versionType": "semver",
"status": "affected"
},
{
"version": "4.14.31",
"lessThan": "4.15",
"versionType": "semver",
"status": "affected"
},
{
"version": "4.15.14",
"lessThan": "4.16",
"versionType": "semver",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"include/linux/mmap_lock.h",
"mm/pagewalk.c",
"mm/vmalloc.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "4.16",
"status": "affected"
},
{
"version": "0",
"lessThan": "4.16",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "5.10.273",
"lessThanOrEqual": "5.10.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "5.15.224",
"lessThanOrEqual": "5.15.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.1.184",
"lessThanOrEqual": "6.1.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.6.153",
"lessThanOrEqual": "6.6.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.12.105",
"lessThanOrEqual": "6.12.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.18.45",
"lessThanOrEqual": "6.18.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "7.1.9",
"lessThanOrEqual": "7.1.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "7.2",
"lessThanOrEqual": "*",
"versionType": "original_commit_for_fix",
"status": "unaffected"
}
]
}
]
}
],
"metrics": {},
"references": [
{
"url": "https://git.kernel.org/stable/c/26444eb71465c9934d9d418ef69c43f61185329b",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/39c6772b56a6bbdd62794833f74232971d94d7c9",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/3cc26c8907db0f5d1ff8043b5851ee572e9b3c98",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/51eaba47b3dc258d1182fc3a88da544ed6b6bb2d",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/7ac8a333dd41ba5e1b4e8c6edbc48b15446c5468",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/8d7f560f4b0482d469de962fbe4b59c37561052e",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/c5bf8cd148cfea948cfa3db71da427294b20db0f",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/e85ed734611616d4a9d8a240bde563dd6ac7452f",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
]
}