CVE-2026-68163

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_vma_mapped: fix device-private PMD handling<br /> <br /> Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support<br /> device-private entries") introduced the concept of device-private PMD<br /> entries, but did not correctly update the rmap walk code to account for<br /> them.<br /> <br /> As a result, when page_vma_mapped_walk() encounters device-private PMD<br /> entries, it takes no action other than to acquire the PMD lock and exit.<br /> <br /> However this is highly problematic for two reasons - firstly, device<br /> private entries possess a PFN so check_pmd() needs to be called to ensure<br /> an overlapping PFN range.<br /> <br /> Secondly, and more importantly, if PVMW_MIGRATION is set the caller<br /> assumes the returned entry is a migration entry, resulting in memory<br /> corruption when the caller tries to interpret the device private entry as<br /> such.<br /> <br /> In addition, commit 146287290023 ("mm/huge_memory: implement<br /> device-private THP splitting") allowed device private PMDs to be split<br /> like THP mappings, but again did not update this code path.<br /> <br /> As a result, we might race a PMD split prior to acquiring the PMD lock.<br /> <br /> This patch addresses all of these issues by invoking check_pmd(), ensuring<br /> PMVW_MIGRATION is not set and checks whether a split raced us we do for<br /> PMD THP and migration entries.<br /> <br /> Instead of checking for a subset of the cases after taking the pmd_lock(),<br /> put device-private along with pmd_trans_huge() and<br /> pmd_is_migration_entry(). Also remove thp_migration_supported() as it is<br /> already guarded by pmd_is_migration_entry().<br /> <br /> [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]