Title: Linux, Description: En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:

mm/huge_memory: corrige el uso de folio NULL en move_pages_huge_pmd()

move_pages_huge_pmd() maneja UFFDIO_MOVE tanto para THPs normales como para páginas cero enormes. Para la ruta de la página cero enorme, src_folio se establece explícitamente en NULL, y se usa como un centinela para omitir operaciones de folio como lock y rmap.

En la rama de la página cero enorme, src_folio es NULL, por lo que folio_mk_pmd(NULL, pgprot) pasa NULL a través de folio_pfn() y page_to_pfn(). Con SPARSEMEM_VMEMMAP esto produce silenciosamente un PFN erróneo, instalando un PMD que apunta a memoria física inexistente. En otros modelos de memoria es una desreferencia NULL.

Usar page_folio(src_page) para obtener el folio cero enorme válido de la página, que se obtuvo de pmd_page() y permanece válido en todo momento.

Después del commit d82d09e48219 ('mm/huge_memory: marcar las asignaciones PMD del folio cero enorme como especiales'), los PMD cero enormes movidos deben permanecer especiales para que vm_normal_page_pmd() continúe tratándolos como asignaciones especiales.

move_pages_huge_pmd() actualmente reconstruye el PMD de destino en la rama de la página cero enorme, lo que elimina el estado del PMD como pmd_special() en arquitecturas con CONFIG_ARCH_HAS_PTE_SPECIAL. Como resultado, vm_normal_page_pmd() puede tratar el PMD cero enorme movido como una página normal y corromper su refcount.

En lugar de reconstruir el PMD a partir del folio, derivar la entrada de destino de src_pmdval después de pmdp_huge_clear_flush(), luego manejar los metadatos del PMD de la misma manera que move_huge_pmd() lo hace para las entradas movidas, marcándolo como soft-dirty y borrando uffd-wp.

[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","programFiles":["mm/huge_memory.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","versions":[{"version":"e3981db444a0a18d350d9f92e3f2e8d489b54211","lessThan":"f3caaee0f9e489fd2282d4ce45791dc8aed2da62","versionType":"git","status":"affected"},{"version":"e3981db444a0a18d350d9f92e3f2e8d489b54211","lessThan":"e3133d0986dc5a231d5419167dbac65312b28b41","versionType":"git","status":"affected"},{"version":"e3981db444a0a18d350d9f92e3f2e8d489b54211","lessThan":"fae654083bfa409bb2244f390232e2be47f05bfc","versionType":"git","status":"affected"}]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","programFiles":["mm/huge_memory.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","versions":[{"version":"6.16","status":"affected"},{"version":"0","lessThan":"6.16","versionType":"semver","status":"unaffected"},{"version":"6.18.20","lessThanOrEqual":"6.18.*","versionType":"semver","status":"unaffected"},{"version":"6.19.10","lessThanOrEqual":"6.19.*","versionType":"semver","status":"unaffected"},{"version":"7.0","lessThanOrEqual":"*","versionType":"original_commit_for_fix","status":"unaffected"}]}]

CWE-476

OR
          *cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
          *cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
          *cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
          *cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
          *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.19 up to (excluding) 6.19.10
          *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.16 up to (excluding) 6.18.20

kernel.org: https://git.kernel.org/stable/c/e3133d0986dc5a231d5419167dbac65312b28b41 Types: Patch

kernel.org: https://git.kernel.org/stable/c/f3caaee0f9e489fd2282d4ce45791dc8aed2da62 Types: Patch

kernel.org: https://git.kernel.org/stable/c/fae654083bfa409bb2244f390232e2be47f05bfc Types: Patch

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved:

mm/huge_memory: fix use of NULL folio in move_pages_huge_pmd()

move_pages_huge_pmd() handles UFFDIO_MOVE for both normal THPs and huge
zero pages.  For the huge zero page path, src_folio is explicitly set to
NULL, and is used as a sentinel to skip folio operations like lock and
rmap.

In the huge zero page branch, src_folio is NULL, so folio_mk_pmd(NULL,
pgprot) passes NULL through folio_pfn() and page_to_pfn().  With
SPARSEMEM_VMEMMAP this silently produces a bogus PFN, installing a PMD
pointing to non-existent physical memory.  On other memory models it is a
NULL dereference.

Use page_folio(src_page) to obtain the valid huge zero folio from the
page, which was obtained from pmd_page() and remains valid throughout.

After commit d82d09e48219 ("mm/huge_memory: mark PMD mappings of the huge
zero folio special"), moved huge zero PMDs must remain special so
vm_normal_page_pmd() continues to treat them as special mappings.

move_pages_huge_pmd() currently reconstructs the destination PMD in the
huge zero page branch, which drops PMD state such as pmd_special() on
architectures with CONFIG_ARCH_HAS_PTE_SPECIAL.  As a result,
vm_normal_page_pmd() can treat the moved huge zero PMD as a normal page
and corrupt its refcount.

Instead of reconstructing the PMD from the folio, derive the destination
entry from src_pmdval after pmdp_huge_clear_flush(), then handle the PMD
metadata the same way move_huge_pmd() does for moved entries by marking it
soft-dirty and clearing uffd-wp.

https://git.kernel.org/stable/c/e3133d0986dc5a231d5419167dbac65312b28b41

https://git.kernel.org/stable/c/f3caaee0f9e489fd2282d4ce45791dc8aed2da62

https://git.kernel.org/stable/c/fae654083bfa409bb2244f390232e2be47f05bfc