Vulnerability-Lookup

FKIE_CVE-2025-22034

Vulnerability from fkie_nvd - Published: 2025-04-16 15:15 - Updated: 2026-07-30 06:22

Severity

7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Summary

In the Linux kernel, the following vulnerability has been resolved: mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs Patch series "mm: fixes for device-exclusive entries (hmm)", v2. Discussing the PageTail() call in make_device_exclusive_range() with Willy, I recently discovered [1] that device-exclusive handling does not properly work with THP, making the hmm-tests selftests fail if THPs are enabled on the system. Looking into more details, I found that hugetlb is not properly fenced, and I realized that something that was bugging me for longer -- how device-exclusive entries interact with mapcounts -- completely breaks migration/swapout/split/hwpoison handling of these folios while they have device-exclusive PTEs. The program below can be used to allocate 1 GiB worth of pages and making them device-exclusive on a kernel with CONFIG_TEST_HMM. Once they are device-exclusive, these folios cannot get swapped out (proc$pid/smaps_rollup will always indicate 1 GiB RSS no matter how much one forces memory reclaim), and when having a memory block onlined to ZONE_MOVABLE, trying to offline it will loop forever and complain about failed migration of a page that should be movable. # echo offline > /sys/devices/system/memory/memory136/state # echo online_movable > /sys/devices/system/memory/memory136/state # ./hmm-swap & ... wait until everything is device-exclusive # echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] page_owner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 [ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 [ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 [ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0 [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 ... This series fixes all issues I found so far. There is no easy way to fix without a bigger rework/cleanup. I have a bunch of cleanups on top (some previous sent, some the result of the discussion in v1) that I will send out separately once this landed and I get to it. I wish we could just use some special present PROT_NONE PTEs instead of these (non-present, non-none) fake-swap entries; but that just results in the same problem we keep having (lack of spare PTE bits), and staring at other similar fake-swap entries, that ship has sailed. With this series, make_device_exclusive() doesn't actually belong into mm/rmap.c anymore, but I'll leave moving that for another day. I only tested this series with the hmm-tests selftests due to lack of HW, so I'd appreciate some testing, especially if the interaction between two GPUs wanting a device-exclusive entry works as expected. <program> #include <stdio.h> #include <fcntl.h> #include <stdint.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <sys/mman.h> #include <sys/ioctl.h> #include <linux/types.h> #include <linux/ioctl.h> #define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, struct hmm_dmirror_cmd) struct hmm_dmirror_cmd { __u64 addr; __u64 ptr; __u64 npages; __u64 cpages; __u64 faults; }; const size_t size = 1 * 1024 * 1024 * 1024ul; const size_t chunk_size = 2 * 1024 * 1024ul; int m ---truncated---

References

URL	Tags
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/2e877ff3492267def06dd50cb165dc9ab8838e7d	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/48d28417c66cce2f3b0ba773fcb6695a56eff220	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/8977752c8056a6a094a279004a49722da15bace3	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/fd900832e8440046627b60697687ab5d04398008	Patch

Impacted products

Vendor	Product	Version
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/gup.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "2e877ff3492267def06dd50cb165dc9ab8838e7d",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            },
            {
              "lessThan": "48d28417c66cce2f3b0ba773fcb6695a56eff220",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            },
            {
              "lessThan": "fd900832e8440046627b60697687ab5d04398008",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            },
            {
              "lessThan": "8977752c8056a6a094a279004a49722da15bace3",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/gup.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.10"
            },
            {
              "lessThan": "6.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.23",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.13.*",
              "status": "unaffected",
              "version": "6.13.11",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.14.*",
              "status": "unaffected",
              "version": "6.14.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.15",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "CD08468B-6C62-4470-90F6-7F16F10CF3B4",
              "versionEndExcluding": "6.12.23",
              "versionStartIncluding": "6.10",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "E7E864B0-8C00-4679-BA55-659B4C9C3AD3",
              "versionEndExcluding": "6.13.11",
              "versionStartIncluding": "6.13",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "FADAE5D8-4808-442C-B218-77B2CE8780A0",
              "versionEndExcluding": "6.14.2",
              "versionStartIncluding": "6.14",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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 \u003e /sys/devices/system/memory/memory136/state\n# echo online_movable \u003e /sys/devices/system/memory/memory136/state\n# ./hmm-swap \u0026\n... wait until everything is device-exclusive\n# echo offline \u003e /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\u0027t actually belong into\nmm/rmap.c anymore, but I\u0027ll leave moving that for another day.\n\nI only tested this series with the hmm-tests selftests due to lack of HW,\nso I\u0027d appreciate some testing, especially if the interaction between two\nGPUs wanting a device-exclusive entry works as expected.\n\n\u003cprogram\u003e\n#include \u003cstdio.h\u003e\n#include \u003cfcntl.h\u003e\n#include \u003cstdint.h\u003e\n#include \u003cunistd.h\u003e\n#include \u003cstdlib.h\u003e\n#include \u003cstring.h\u003e\n#include \u003csys/mman.h\u003e\n#include \u003csys/ioctl.h\u003e\n#include \u003clinux/types.h\u003e\n#include \u003clinux/ioctl.h\u003e\n\n#define HMM_DMIRROR_EXCLUSIVE _IOWR(\u0027H\u0027, 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---"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: rechazo de FOLL_SPLIT_PMD con VMAs hugetlb. Serie de parches \"mm: correcciones para entradas exclusivas de dispositivo (hmm)\", v2. Al hablar con Willy sobre la llamada a PageTail() en make_device_exclusive_range(), descubr\u00ed recientemente [1] que la gesti\u00f3n exclusiva de dispositivo no funciona correctamente con THP, lo que provoca que las autopruebas hmm-tests fallen si las THP est\u00e1n habilitadas en el sistema. Al analizar m\u00e1s a fondo, descubr\u00ed que hugetlb no est\u00e1 correctamente protegido y me di cuenta de que algo que me hab\u00eda estado molestando durante mucho tiempo (la interacci\u00f3n de las entradas exclusivas de dispositivo con mapcounts) interrumpe por completo la gesti\u00f3n de migraci\u00f3n/intercambio/divisi\u00f3n/hwpoison de estos folios mientras tienen PTE exclusivas de dispositivo. El programa a continuaci\u00f3n se puede usar para asignar 1 GiB de p\u00e1ginas y convertirlas en exclusivas de dispositivo en un kernel con CONFIG_TEST_HMM. Una vez que son exclusivos del dispositivo, estos folios no se pueden intercambiar (proc$pid/smaps_rollup siempre indicar\u00e1 1 GiB RSS sin importar cu\u00e1nto se fuerce la recuperaci\u00f3n de memoria) y cuando se tiene un bloque de memoria en l\u00ednea en ZONE_MOVABLE, al intentar desconectarlo se repetir\u00e1 eternamente y se quejar\u00e1 sobre la migraci\u00f3n fallida de una p\u00e1gina que deber\u00eda ser movible. # echo offline \u0026gt; /sys/devices/system/memory/memory136/state # echo online_movable \u0026gt; /sys/devices/system/memory/memory136/state # ./hmm-swap \u0026amp; ... wait until everything is device-exclusive # echo offline \u0026gt; /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] page_owner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 [ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 [ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 [ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0 [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 ... Esta serie corrige todos los problemas que he encontrado hasta ahora. No hay una soluci\u00f3n sencilla sin una revisi\u00f3n o limpieza m\u00e1s profunda. Tengo varias correcciones adicionales (algunas enviadas previamente, otras resultantes de la discusi\u00f3n en la v1) que publicar\u00e9 por separado una vez que est\u00e9 disponible y pueda con ello. Ojal\u00e1 pudi\u00e9ramos usar algunas PTE PROT_NONE presentes especiales en lugar de estas entradas de intercambio falso (no presentes, no ninguna); pero eso solo resulta en el mismo problema que seguimos teniendo (falta de bits de PTE de repuesto), y al observar otras entradas de intercambio falso similares, ese barco ya pas\u00f3. Con esta serie, make_device_exclusive() ya no pertenece a mm/rmap.c, pero lo dejar\u00e9 para otro d\u00eda. Solo prob\u00e9 esta serie con las autopruebas hmm-tests debido a la falta de hardware, as\u00ed que agradecer\u00eda algunas pruebas, especialmente si la interacci\u00f3n entre dos GPU que buscan una entrada de dispositivo exclusivo funciona como se espera.  #include  #include  #include  #include  #include  #include  #include  #include  #include  #include  #define HMM_DMIRROR_EXCLUSIVE _IOWR(\u0027H\u0027, 0x05, ---truncado---"
    }
  ],
  "id": "CVE-2025-22034",
  "lastModified": "2026-07-30T06:22:04.373",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2025-04-16T15:15:56.013",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/2e877ff3492267def06dd50cb165dc9ab8838e7d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/48d28417c66cce2f3b0ba773fcb6695a56eff220"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/8977752c8056a6a094a279004a49722da15bace3"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/fd900832e8440046627b60697687ab5d04398008"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "NVD-CWE-noinfo"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

CVE-2025-22034 (GCVE-0-2025-22034)

Vulnerability from cvelistv5 – Published: 2025-04-16 14:11 – Updated: 2026-08-05 11:56

Title

mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs

Summary

Severity

7.8 (High)


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

Assigner

Linux mitre root

References

4 references

URL	Tags
https://git.kernel.org/stable/c/2e877ff3492267def…
https://git.kernel.org/stable/c/48d28417c66cce2f3…
https://git.kernel.org/stable/c/fd900832e84400466…
https://git.kernel.org/stable/c/8977752c8056a6a09…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 9cb28da54643ad464c47585cd5866c30b0218e67 , < 2e877ff3492267def06dd50cb165dc9ab8838e7d (git) Affected: 9cb28da54643ad464c47585cd5866c30b0218e67 , < 48d28417c66cce2f3b0ba773fcb6695a56eff220 (git) Affected: 9cb28da54643ad464c47585cd5866c30b0218e67 , < fd900832e8440046627b60697687ab5d04398008 (git) Affected: 9cb28da54643ad464c47585cd5866c30b0218e67 , < 8977752c8056a6a094a279004a49722da15bace3 (git)
Linux	Linux	Affected: 6.10 Unaffected: 0 , < 6.10 (semver) Unaffected: 6.12.23 , ≤ 6.12.* (semver) Unaffected: 6.13.11 , ≤ 6.13.* (semver) Unaffected: 6.14.2 , ≤ 6.14.* (semver) Unaffected: 6.15 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/gup.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "2e877ff3492267def06dd50cb165dc9ab8838e7d",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            },
            {
              "lessThan": "48d28417c66cce2f3b0ba773fcb6695a56eff220",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            },
            {
              "lessThan": "fd900832e8440046627b60697687ab5d04398008",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            },
            {
              "lessThan": "8977752c8056a6a094a279004a49722da15bace3",
              "status": "affected",
              "version": "9cb28da54643ad464c47585cd5866c30b0218e67",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/gup.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.10"
            },
            {
              "lessThan": "6.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.23",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.13.*",
              "status": "unaffected",
              "version": "6.13.11",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.14.*",
              "status": "unaffected",
              "version": "6.14.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.15",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.23",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13.11",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14.2",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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 \u003e /sys/devices/system/memory/memory136/state\n# echo online_movable \u003e /sys/devices/system/memory/memory136/state\n# ./hmm-swap \u0026\n... wait until everything is device-exclusive\n# echo offline \u003e /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\u0027t actually belong into\nmm/rmap.c anymore, but I\u0027ll leave moving that for another day.\n\nI only tested this series with the hmm-tests selftests due to lack of HW,\nso I\u0027d appreciate some testing, especially if the interaction between two\nGPUs wanting a device-exclusive entry works as expected.\n\n\u003cprogram\u003e\n#include \u003cstdio.h\u003e\n#include \u003cfcntl.h\u003e\n#include \u003cstdint.h\u003e\n#include \u003cunistd.h\u003e\n#include \u003cstdlib.h\u003e\n#include \u003cstring.h\u003e\n#include \u003csys/mman.h\u003e\n#include \u003csys/ioctl.h\u003e\n#include \u003clinux/types.h\u003e\n#include \u003clinux/ioctl.h\u003e\n\n#define HMM_DMIRROR_EXCLUSIVE _IOWR(\u0027H\u0027, 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---"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "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\u0027s 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\u0027s 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\u0027s 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."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:56:06.819Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/2e877ff3492267def06dd50cb165dc9ab8838e7d"
        },
        {
          "url": "https://git.kernel.org/stable/c/48d28417c66cce2f3b0ba773fcb6695a56eff220"
        },
        {
          "url": "https://git.kernel.org/stable/c/fd900832e8440046627b60697687ab5d04398008"
        },
        {
          "url": "https://git.kernel.org/stable/c/8977752c8056a6a094a279004a49722da15bace3"
        }
      ],
      "title": "mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-22034",
    "datePublished": "2025-04-16T14:11:53.301Z",
    "dateReserved": "2024-12-29T08:45:45.808Z",
    "dateUpdated": "2026-08-05T11:56:06.819Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.