{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-22034", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-22034" ], "published": "2025-04-16T14:14:59Z", "summary": "mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs\n\nPatch series \"mm: fixes for device-exclusive entries (hmm)\", v2.\n\nDiscussing the PageTail() call in make_device_exclusive_range() with\nWilly, I recently discovered [1] that device-exclusive handling does not\nproperly work with THP, making the hmm-tests selftests fail if THPs are\nenabled on the system.\n\nLooking into more details, I found that hugetlb is not properly fenced,\nand I realized that something that was bugging me for longer -- how\ndevice-exclusive entries interact with mapcounts -- completely breaks\nmigration/swapout/split/hwpoison handling of these folios while they have\ndevice-exclusive PTEs.\n\nThe program below can be used to allocate 1 GiB worth of pages and making\nthem device-exclusive on a kernel with CONFIG_TEST_HMM.\n\nOnce they are device-exclusive, these folios cannot get swapped out\n(proc$pid/smaps_rollup will always indicate 1 GiB RSS no matter how much\none forces memory reclaim), and when having a memory block onlined to\nZONE_MOVABLE, trying to offline it will loop forever and complain about\nfailed migration of a page that should be movable.\n\n# echo offline > /sys/devices/system/memory/memory136/state\n# echo online_movable > /sys/devices/system/memory/memory136/state\n# ./hmm-swap &\n... wait until everything is device-exclusive\n# echo offline > /sys/devices/system/memory/memory136/state\n[ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000\n index:0x7f20671f7 pfn:0x442b6a\n[ 285.196618][T14882] memcg:ffff888179298000\n[ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate|\n dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff)\n[ 285.201734][T14882] raw: ...\n[ 285.204464][T14882] raw: ...\n[ 285.207196][T14882] page dumped because: migration failure\n[ 285.209072][T14882] page_owner tracks the page as allocated\n[ 285.210915][T14882] page last allocated via order 0, migratetype\n Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO),\n id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774\n[ 285.216765][T14882] post_alloc_hook+0x197/0x1b0\n[ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280\n[ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740\n[ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540\n[ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340\n[ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0\n[ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0\n[ 285.230822][T14882] handle_mm_fault+0x368/0x9f0\n...\n\nThis series fixes all issues I found so far. There is no easy way to fix\nwithout a bigger rework/cleanup. I have a bunch of cleanups on top (some\nprevious sent, some the result of the discussion in v1) that I will send\nout separately once this landed and I get to it.\n\nI wish we could just use some special present PROT_NONE PTEs instead of\nthese (non-present, non-none) fake-swap entries; but that just results in\nthe same problem we keep having (lack of spare PTE bits), and staring at\nother similar fake-swap entries, that ship has sailed.\n\nWith this series, make_device_exclusive() doesn't actually belong into\nmm/rmap.c anymore, but I'll leave moving that for another day.\n\nI only tested this series with the hmm-tests selftests due to lack of HW,\nso I'd appreciate some testing, especially if the interaction between two\nGPUs wanting a device-exclusive entry works as expected.\n\n\n#include \n#include \n#include \n#include \n#include \n#include \n#include \n#include \n#include \n#include \n\n#define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, struct hmm_dmirror_cmd)\n\nstruct hmm_dmirror_cmd {\n\t__u64 addr;\n\t__u64 ptr;\n\t__u64 npages;\n\t__u64 cpages;\n\t__u64 faults;\n};\n\nconst size_t size = 1 * 1024 * 1024 * 1024ul;\nconst size_t chunk_size = 2 * 1024 * 1024ul;\n\nint m\n---truncated---", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.12.20-1+rpt1~bpo12+1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v6", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7l", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" } ] }, "database_specific": { "per_version": { "1:6.12.20-1+rpt1~bpo12+1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.23" } } } }, { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.12.19-1+rpt1~bpo12+1", "1:6.12.19-1+rpt1", "1:6.12.20-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v6", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7l", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v6", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v7l", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v6", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v7l", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.12.19-1+rpt1~bpo12+1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.23" }, "1:6.12.19-1+rpt1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.23" }, "1:6.12.20-1+rpt1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.23" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-22034" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2e877ff3492267def06dd50cb165dc9ab8838e7d" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/48d28417c66cce2f3b0ba773fcb6695a56eff220" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/fd900832e8440046627b60697687ab5d04398008" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8977752c8056a6a094a279004a49722da15bace3" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - Triggering requires local access \u2014 mmap of a hugetlb region plus DRM render-node ioctls to set up nouveau SVM and issue a GPU atomic fault (or the `/dev/hmm_dmirror` ioctl on CONFIG_TEST_HMM kernels). There is no network-reachable path to `make_device_exclusive_range()`.\nAC:L - No race or memory-layout luck is involved; the attacker deterministically creates the hugetlb VMA and directs a GPU atomic access at it, and `pmd_trans_huge()` is unconditionally true for a PMD-sized hugetlb entry. Nouveau SVM is enabled in mainstream distro kernels and hugepage pools are standard on GPU/HPC/database hosts, so nothing required is outside the attacker's control.\nPR:L - `NOUVEAU_SVM_INIT`/`NOUVEAU_SVM_BIND` are `DRM_RENDER_ALLOW`, reachable by any user who can open `/dev/dri/renderD*` (world- or render-group accessible on desktops and GPU compute nodes), and `mmap(MAP_ANONYMOUS|MAP_HUGETLB)` requires no capability. A plain unprivileged local account suffices.\nUI:N - The attacking process performs every step itself \u2014 allocating the hugetlb mapping, binding SVM, and issuing the GPU atomic operation. No victim action or cooperation is needed.\nS:U - The page-table and hugetlb-folio corruption occurs within the kernel that already manages the attacking process, yielding standard local privilege escalation. No VM, IOMMU, or other security-authority boundary is crossed.\nC:H - After the PMD is replaced with a normal PTE table, `hugetlb_wp()` calls `copy_user_large_folio()` with the page-table page as the source, copying raw PTE contents \u2014 physical addresses defeating KASLR/physmap randomization \u2014 into an attacker-readable hugepage. The subsequent use-after-free on the freed page table gives a broad kernel read primitive.\nI:H - `folio_put()`/`hugetlb_remove_rmap()` are applied to a page-table page that is still installed in the process's page tables, so it is freed and reallocated while live, giving stale PTEs that translate to arbitrary physical memory \u2014 a direct arbitrary-write primitive. Hugetlb folio refcount underflow and corrupted RSS/mapcount accounting compound this.\nA:H - The commit's own trace shows an immediate `kernel BUG at mm/page_table_check.c:87` (`Oops: invalid opcode`) from `pmdp_huge_clear_flush()` under CONFIG_PAGE_TABLE_CHECK. Without that debug option the resulting page-table corruption and refcount underflow reliably panic the kernel, and the trigger is repeatable at will." } } }